In this guide 6 sections
Vet the vendor before the price. Have a legal adviser review the written scope, milestones, access, confidentiality and ownership terms before signing, and keep the repository and every account under your own organisation. Agree escalation and exit early. Skipped steps cause disputes.
Vet the vendor before the proposal
A polished proposal proves little. The gap between proposal and delivery only shows once work starts, so ask for references from businesses of similar size instead of logos on a website. Ask each reference about a problem. How the vendor handled a missed deadline or a changed requirement reveals more than whether the product eventually worked on launch day.
Test continuity as well. Ask how long this specific team has worked together, what happens if the assigned developer leaves mid-project, and whether the vendor usually serves businesses of your size. A poor size match is costly. A vendor used to much smaller jobs tends to under-resource yours, while one used to enterprise engagements tends to over-engineer it and bury the team in process.
Meet the actual team. Insist on speaking to the developers and project manager who will build your system, and ask to read documentation from a past project.
Define scope, milestones and acceptance evidence
Vague scope protects nobody. Scope must be specific enough that both sides can point to one document and agree whether a feature is inside or outside the price. Tie milestones to working features. An order module that handles a full order lifecycle including returns can be verified, whereas a report saying the work is mostly done cannot.
Acceptance evidence settles arguments. It is what must be shown before a milestone counts as met, and it should be agreed before work starts instead of negotiated after the vendor calls it finished. Disputes about inclusion shrink.
Payment should follow proof. Link each payment to an accepted milestone rather than elapsed time, so money moves when working features are demonstrated and not when the calendar says another month has passed.
Access, confidentiality and ownership terms for review
Have a legal adviser review three points. These questions depend on your situation and jurisdiction, so confirm the current rules with an adviser instead of settling them from a template alone.
Suppose a fintech outsources reconciliation. Financial data is sensitive, so confidentiality and data-handling terms deserve legal scrutiny before any transaction file is shared, and a generic NDA signed as a formality is not enough.
Cover the data trail. Ask where the vendor stores copies of your files, who on their team can open them, and what happens to those copies when the contract ends.
- Confidentiality and permitted data use
- Ownership of the intellectual property
- Liability if something goes wrong
Keep repositories and accounts under your control
Create every account yourself. From day one, open the code repository, hosting account and related third-party accounts under your own organisation, and grant the vendor scoped access to work inside them. Letting the vendor register them first hands over your bargaining power, while ownership from day one means nobody can withhold access during a dispute.
This is a standard precaution. A credible partner expects it and works inside it without friction, and a vendor that resists is telling you something worth hearing before you sign. For a small vendor, ask for a source-code escrow arrangement so the repository is released to you if the company closes or stops answering messages.
Share logins through a vault. Removing a departing developer then takes one action, instead of searching scattered logins, shared spreadsheets and old chat messages that nobody remembers to clean up.
Plan escalation, continuity and exit
Agree the bad day in writing. Name who you escalate to when the team underperforms, how a milestone disagreement gets resolved, and what notice and handover process applies if either side ends the engagement.
Keep your own records. Document the system’s architecture and key decisions yourself, so the vendor’s memory is never the only copy of how your software works. Test your access every quarter. Confirm that you still hold working access to everything on the handover checklist during a long engagement, not only when the project ends.
- Escalation contact above the project team
- Written milestone dispute process
- Notice period and handover steps
Outsourcing risk-control matrix
A matrix pairing five risks with one control each, from reference checks for vendor reliability to a written exit clause for exit friction. Check your arrangement before signing.
Open a blank worksheet to printQuestions owners ask
Should the vendor own our hosting account?
No, you should own it. Create hosting, repository and related accounts under your organisation from the start and give the vendor scoped access, so a disagreement cannot lock you out of the system.
How do we reduce single-vendor dependence?
Keep your own records. Document the architecture and key decisions, confirm your organisation controls every repository and account, and test access regularly instead of assuming it works until the day you need it.
Is an NDA enough protection?
Rarely, on its own. A generic template covers confidentiality only, so scope, ownership, liability, acceptance evidence and exit terms still need their own written clauses reviewed by a legal adviser.
When should a lawyer get involved?
Before anything is signed. Ask for a review of the confidentiality, ownership, liability and termination clauses, because paying for wording to be checked early costs less than arguing about it later.