Most labs reach the point where a script that one student wrote has become something the whole group depends on. Bringing in an outside team to turn it into real software is a reasonable step, and the questions below are the ones that decide whether the result will still work after the people who asked for it have moved on. If you want to see the kind of work involved first, read about Software & AI Development for Academia & Research.
Who owns the code and the data?
Ask this before anything else. The code should sit in a repository the institution controls, from the first commit, and the data should stay in your environment. A team that keeps the code on its own servers until the last invoice is paid creates a dependency you will feel at the worst moment, usually right before a submission.
Check what the university requires. Many institutions have rules on research data, on cloud regions and on who may see identifiable information. A good team asks for those rules early and designs around them. Many funders also expect research data to be findable, accessible, interoperable and reusable, as set out in the FAIR principles, first published in Scientific Data.
Will someone else be able to run it next year?
Research software usually fails quietly. The person who wrote it leaves, a library updates, and nobody can reproduce last year's figures. Ask the team how they will make the tool runnable by someone new: a short README that actually works on a clean machine, pinned dependencies, and tests on the parts that produce results.
Ask to see the handover. A walkthrough recorded for the next student is worth more than a long document nobody reads.
