Choose a software development partner by verifying three things in writing before you pay a deposit: who will actually write the code, that you own the result outright, and how you get out if the work goes wrong. Portfolios and review scores predict very little. Named engineers, specific contract terms and a small paid pilot predict most of it.
How much diligence does this project deserve?
Match the depth of your vetting to what failure would cost you. Federal banking regulators use a test that transfers cleanly: an activity counts as critical if failure by the third party could expose the organization to significant risk, have significant customer impact, or significantly affect its financial condition or operations, and effective management of the relationship runs as a five-stage life cycle of planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination, according to a summary of the 2023 interagency guidance.
The underlying final guidance from the Federal Reserve Board, FDIC and OCC, effective June 6, 2023, sets out risk management principles for all stages of that life cycle, and the agencies are careful to say their own examples are not a checklist. Most buyers spend their energy on stage two, comparing proposals. Stages three and five, contract negotiation and termination, are where most outcomes are decided, so spend the time there.
A simple rule for scaling your effort:
- Light diligence if the system holds no customer or personal data, a rebuild would take a few weeks, and switching vendors costs little: check references, insist on repository access, keep the contract short.
- Heavy diligence if the software touches money, health records, customer accounts or regulated reporting, or if losing the partner would stall your operations: named team, security review, data processing terms, escrow discussion, staged payments tied to acceptance.
Who will actually write your code?
Ask for the specific people, by name and role, and ask whether they are employees of the legal entity signing your contract. The most common gap between a sales meeting and a delivery team is seniority: the architect who impressed you in the pitch is often allocated a token share of the plan while daily work sits with whoever was free. Get the allocation in writing as a percentage of each person's week, and ask what happens if that person leaves mid-project.
Subcontracting deserves its own clause. If your product handles UK or EU personal data, the UK regulator sets out that a processor must not engage a sub-processor without the controller's prior written authorisation, must tell you about intended changes so you can object, and must impose the same data protection obligations on that sub-processor, per the ICO's guidance on controller and processor contracts and Article 28 of the GDPR. With no European users, borrow the mechanism anyway: written consent before anyone outside the signing company touches your code or your data.
Offshore and distributed teams work fine when the chain is disclosed; a local shop quietly reselling capacity is the harder problem.
Do you own the code you paid for?
Paying an invoice does not, on its own, make you the copyright owner. A "work made for hire" is an exception to the normal rule that the person who created the work is the author, and for commissioned work the U.S. Copyright Office describes a sequential test: a written agreement, signed by both the commissioning party and the creator, expressly agreeing the work is made for hire, covering work that falls within the listed categories. If any element is missing, it is not a work made for hire. The Copyright Office also notes that the parties themselves must determine this; no agency rules on it for you.
This is why a practitioner guide to the doctrine published by the DuPage County Bar Association recommends including both a work for hire provision and a separate copyright assignment in contractor agreements, signed before any work starts, so ownership holds whether or not the deliverable fits a statutory category. Belt and braces, for a few extra lines of text.
Then ask the question almost nobody asks. Contractors reuse existing code and internal modules rather than rebuilding everything, and that same guide points out you need confirmation the contractor had permission to use those pre-existing works. Request a written list of anything reused from the vendor's own library, anything licensed from a third party, and the open source dependencies with their licenses. Have counsel read those license terms before launch, or you may own the parts written for you and merely license the parts holding them together.
Which contract terms decide the outcome?
Most disputes trace back to five or six clauses that were never negotiated. Work through this list with the vendor before you sign anything, and treat resistance to any single row as information.
| Term | What it protects | What to insist on |
|---|---|---|
| IP assignment plus work for hire | Ownership of the delivered code | Both clauses, signed before work begins |
| Pre-existing and third-party components | Your right to keep using the whole product | Written inventory, license list, warranty of right to use |
| Subcontracting consent | Knowing who touches code and data | No subcontractor without your prior written approval |
| Acceptance criteria | A shared definition of "done" | Testable criteria per milestone, a review window, a named approver |
| Accounts and credentials | Continuity if the relationship ends | Repository, cloud, domain and CI accounts in your name from day one |
| Termination and transition | A clean exit | Notice period, paid transition assistance, documentation standard at handover |
Add a payment schedule that leaves something meaningful unpaid until the final milestone is accepted, and check that the liability cap and the vendor's insurance are proportionate to the damage a defect could do: a cap equal to fees paid is fine for an internal tool and thin comfort for a payment system.
AIoptimix works this way: a fixed written scope before work starts, weekly demos, and the client owning the code and accounts.
If you are still weighing whether a custom build is justified at all, the decision belongs before the vendor question, and our guide to build versus buy for core systems works through it.
How much should it cost, and how do you spot an underpriced bid?
Sanity check a quote against published wage data rather than against other quotes. The U.S. Bureau of Labor Statistics reports a median annual wage of $109,470 for computer and information technology occupations in May 2025, against $50,980 for all workers. The median annual wage for software quality assurance analysts and testers was $104,300 in May 2025, and for web and digital interface designers $104,000. Base salary is a floor, not a cost: payroll taxes, benefits, equipment, recruiting and management sit on top before anyone has earned a margin.
So ask for the quote broken down by role, hours per role, and rate per role. If the implied cost per engineer per month is far below what employing that person locally would cost, one of three things is true: the work is going to less experienced people, it is being subcontracted, or the low number is an entry price that change orders will correct. Offshore rates are genuinely lower for real labor-cost reasons, which is different from a bid that cannot mathematically cover the promised team.
On engagement model, a short rule:
- Fixed price when the scope is genuinely stable and written down. It transfers estimation risk to the vendor, and they will price that risk in.
- Time and materials when discovery is still happening. Cap it per sprint, require a burn report, and keep the right to stop.
- Dedicated team when the work continues past launch and you want the same people to keep the context, which is what a dedicated development team arrangement is for.
What are the warning signs and common mistakes?
The strongest predictor of a bad delivery is a sales process with no friction in it. A vendor who accepts your scope, your timeline and your budget without challenging a single assumption is either not reading the scope or planning to renegotiate later. Experienced teams push back early, because that is when pushing back is cheap.
Warning signs worth acting on:
- Refusal to name the engineers, or a roster that changes between proposal and kickoff.
- Reluctance to give you repository and cloud account ownership on day one.
- A certification badge with no report, no scope statement, no date, or an audited entity name that does not match the entity on your contract.
- References that are all several years old, or reachable only through the account manager.
- Testing described as "we test everything", with no answer on code review, automated tests, or how a release reaches production.
The buyer-side mistakes are just as consistent. The biggest is assigning no internal owner, then finding the project stalled because nobody on your side could answer questions or accept a milestone. The second is leaving quality unexamined until launch, when asking early about code review and automated testing costs you one conversation. Our guide to why IT projects fail traces the pattern behind several of these.
What if the project is already failing?
Stop paying for future work and buy information first. Ask for read access to the repository and the deployment pipeline today, then have an independent engineer spend a day answering three questions: does the code build from a clean checkout, do the delivered features match the accepted milestones, and how much of what exists is reusable. That assessment usually costs less than a week of the vendor's fees and it decides everything that follows.
If the answers are bad, your position is only as strong as the contract made it: unpaid milestones, notice periods, transition assistance, account ownership. If they are mixed, a scope reset around a narrower first release usually beats a rebuild.
Before you compare another proposal, write down what failure would cost you and draft the six contract terms above. Then buy a two-week paid pilot from your leading candidate and judge the working code, not the deck.