Introduction
Most guides to choosing a software development partner focus on the wrong things: hourly rates, headcount, a portfolio of logos. Those matter at the margins. The decision that actually determines whether the engagement was worth it is quieter: what are you left with when it ends? A partner can ship something impressive and still leave you with code you cannot maintain, a bill that never stops, and no real ownership of the thing your business now depends on.
This is a vendor-neutral checklist for evaluating an enterprise software delivery partner, organized around the questions that reveal how an engagement will actually turn out.
1. Ownership: what do you own, and from when?
Get specific, in writing. Do you own the source code, or a license to use it? Do you own the intellectual property in what was built? When does ownership transfer — at the end, on final payment, or from the first commit?
The strongest position is unambiguous: you own the source, the IP, and everything built, from day one. Anything short of that — code held until final payment, IP shared or retained, "you own the output but not the framework it runs on" — is a lever the partner can pull later. Ownership is not a formality; it is what lets you walk away.
And ownership only means something if the thing you own is usable. Owning code you cannot read, run, or extend is ownership on paper. Which leads directly to the next question.
2. Lock-in: how hard is it to leave?
Lock-in is rarely stated; it is engineered in. The questions that expose it:
Is it built on a standard, well-known stack, or a proprietary framework/runtime only this partner understands?
Does anything depend on the partner's own infrastructure or services to keep running?
If you took the codebase to a different vendor tomorrow, could they run and extend it without a lengthy reverse-engineering effort?
Is there a clean export of everything — code, configuration, data, documentation?
A partner confident in their work makes leaving easy, because they are not relying on switching costs to keep you. If the honest answer to "can we take this in-house or elsewhere?" is complicated, you have found the lock-in.
3. Security and data: where does your code and data go?
For any regulated enterprise this can be a deal-breaker on its own:
Does your source code or data leave your environment to be processed — and if so, where does it go and who can see it?
Can the work run in your own cloud or, where required, air-gapped?
Is any of your code or data used to train models or improve the vendor's product?
What certifications and controls (SOC 2, ISO 27001, and the frameworks specific to your industry) are in place, and will they show you the evidence under NDA?
"Your data stays in your environment and is never used to train anything" should be a clear yes, not a paragraph of qualifications.
4. Accountability and quality: who signs off, and against what?
Speed is easy to demonstrate; defensibility is not. Ask how quality is actually enforced before anything ships:
Who reviews and signs off on a release, and are they separate from whoever (or whatever) did the work?
Is there a standard the work is reviewed against, or is "looks good" the bar?
Is there an audit trail — a traceable record from requirement to shipped code — that would satisfy your own auditors?
How is testing handled: real coverage of the risky paths, or a demo and a promise?
This matters more, not less, as partners adopt AI to generate code. More code produced faster raises the importance of a named human accountable for what ships and a record behind the decision.
5. Maintainability: can your team run it afterward?
The engagement ends; the software lives on. Will your own engineers be able to operate and extend it?
Is the code documented and tested to a standard your team can pick up?
Does it follow conventions your team already uses, or one-off patterns?
Is there a real handover — specification, architecture, tests, and the audit trail — or just a repository dropped over the wall?
A system your team cannot maintain becomes a permanent dependency on the partner, which is lock-in by another name.
6. Engagement model: staff-aug, project, or a done-for-you outcome?
Three broad models, with different risk profiles:
Staff augmentation rents you people. You still own the delivery, the risk, and the management overhead; you have simply added hands.
Project / fixed-scope buys a defined deliverable, but quality and ownership terms vary widely — this is where the questions above matter most.
Done-for-you outcome takes responsibility for delivering a finished, running result. The upside is you carry less of the delivery risk; the thing to verify is that "done-for-you" comes with ownership and no lock-in, not instead of them.
There is no universally right model — only the right fit for how much of the delivery risk you want to hold. But whichever you choose, the ownership, lock-in, security, and accountability questions apply.
The checklist
Before you sign, get clear answers to:
1. Do we own the source and IP, and from when?
2. Is it a standard, exportable stack with no proprietary runtime?
3. Does our code or data ever leave our environment, or train anyone's models?
4. Who signs off before a release, against what standard, with what audit trail?
5. Can our own engineers read, run, and extend the result?
6. If we wanted to leave tomorrow, what exactly would we take, and could someone else run it?
(A done-for-you model where AI-agentic teams and human experts deliver the finished software, you own the code and IP from the first commit, and nothing locks you in, is the premise Tmob AI Studio is built on.) Whoever you choose, make them answer these six questions before the work starts — not after.