A buyer's guide to outsourcing development
For teams commissioning software for the first time — what's worth knowing before you sign. It's a general guide: it holds whether or not you work with us.
Write three lines before you start
You don't need a spec to start. But three lines, one sentence each, will let you open a conversation with any vendor.
- What you're building — the core feature in one sentence
- Why — what has to change after launch for it to count as success
- By when — and the reason behind that date
Read the scope, not the total
Two quotes for 'an app' can cover very different things. One includes the admin screens, the server, tests, documentation and deployment; the other is screens only. Their totals cannot be compared.
Before the number, check three things.
- Is there an itemised list of what's included and excluded?
- Is payment split into milestones?
- How are scope changes handled mid-project?
Five clauses to look for in the contract
Your own standard contract or the vendor's — either works. Whichever it is, make sure these five exist as clauses.
- When intellectual property transfers to you
- What the deliverables include — documents, accounts and settings, not just code
- The defect-liability period
- The cap on damages
- How late-delivery penalties are calculated
Repositories and accounts in your name, from day one
Starting with everything in your name is safer than receiving it at the end. If the vendor disappears or the relationship sours, the work stays in your hands.
Before kickoff, confirm who owns the code repository and the cloud accounts — and check the contract doesn't make handover conditional on the vendor's consent.
Judge progress by a running product, not a document
A phrase like 'almost done' cannot be verified. Ask instead for something you can install and run, delivered at a fixed cadence.
Tap through it yourself and you can judge without any development background — what works and what doesn't is right there on the screen.
Signals worth a second look
If any of these apply before you sign, ask why. There may be a fair reason — but if it goes unexplained, you pay for it later.
- No list of deliverables in the contract
- The repository or cloud accounts are in the vendor's name
- Handover requires the vendor's consent
- No interim builds — everything revealed only at the end
Questions to ask a vendor
How specific the answers are tells you how skilled the vendor is. Sign with the one that answers without hesitation.
- Who approves code before it ships? Can we know their name?
- How do you test? Can we see the records?
- If we switch vendors mid-project, how does handover work?
- What are the maintenance terms after launch?
- Do you use AI tools? If so, which of our data goes to them — and where?
If you've read this far, you're ready
Send us the three lines from the first section. We'll start by shaping the scope with you.