Most selection processes compare price and portfolio. Neither predicts the outcome well. These are the checks that do — including the contract clauses that decide whether you can leave.
Choosing a development partner is difficult precisely because the thing you are assessing is the thing you lack expertise in. The standard process — collect three quotes, look at portfolios, pick a number you are comfortable with — selects for sales ability rather than delivery ability. Here is what actually predicts the outcome.
Establish who will do the work
Ask directly: will the people in this meeting be building the system? In a meaningful share of engagements the senior staff presenting are not the staff delivering, and the work is passed to a more junior team or subcontracted entirely. This is not automatically disqualifying, but you should know before signing rather than at the first status call.
- Who specifically will write the code, and what is their experience with this kind of system?
- Will the work be subcontracted, in whole or in part?
- Who is my point of contact when something goes wrong, and what is their authority to fix it?
- What happens if the lead developer leaves mid-project?
Check references rather than portfolios
A portfolio shows what shipped. It does not show whether it was late, whether the budget doubled, or whether the client would use them again. Ask for two references: one recent, and one from a project that finished at least a year ago. The second is more revealing — it tells you whether the software was still working and supported after the invoices stopped.
Watch what happens when you ask a hard question
Describe a requirement that is genuinely difficult or ambiguous and see what comes back. A capable supplier asks clarifying questions, identifies the risks, and may tell you the requirement as stated is a bad idea. A less capable one agrees enthusiastically and quotes immediately.
Willingness to disagree with you during the sales process is among the more reliable indicators available. Someone who says yes to everything before a contract exists will not suddenly develop judgement after it does.
The contract terms that matter
| Term | What you want | Why |
|---|---|---|
| IP ownership | You own all code and assets on payment | Without this you may be licensing your own system |
| Repository access | Your organisation's account, from day one | You can see progress and you are not locked out in a dispute |
| Hosting and domains | Registered in your name | The most common form of lock-in, and the easiest to prevent |
| Change process | Written, with pricing agreed in advance | Prevents renegotiation of every adjustment |
| Acceptance criteria | Defined per phase before it starts | Gives 'finished' an objective meaning |
| Exit terms | Documented handover included | You will eventually part ways, amicably or not |
The single most useful clause is repository access from the first commit. It costs a supplier nothing to agree to if they are competent and confident, and reluctance to agree tells you something important.
Signals worth treating as warnings
- A fixed quote produced without meaningful discovery. Either the estimate is guesswork or the scope is defined loosely enough to be argued later.
- Guaranteed search rankings or guaranteed traffic. Nobody controls Google's results, and claiming otherwise indicates either misunderstanding or misrepresentation.
- Reluctance to give you repository access, or hosting held in the supplier's name.
- A proposal that is entirely technology names with no reference to your business problem.
- Pressure to sign quickly for a discount that expires.
- No maintenance conversation. A supplier who does not raise ongoing costs is either inexperienced or is leaving you to discover them.
- Testimonials with no attributable names or companies.
A sensible selection process
- Write down the business problem, in business terms. Not the solution you have imagined — the problem, and what success would look like as a measurement.
- Approach three or four suppliers whose experience plausibly fits. More than that dilutes the effort you can give each conversation.
- Pay for discovery with your preferred one or two. Paid discovery produces a real scope and shows you how they work before the large commitment.
- Compare proposals on scope and exclusions, not on the headline figure.
- Take references, including one older project.
- Start with a small, real piece of work if you can. A first phase of genuine value is a far better test than any interview.
- Read the contract properly, with particular attention to IP, change control and exit.
On offshore, nearshore and local
Capable engineers and poor ones exist everywhere, and location predicts quality far less than people assume. What location does affect is communication cost. A large time-zone gap works well with clearly documented requirements and someone on your side actively managing the relationship; it works badly with an evolving brief that needs daily conversation.
Be straightforwardly practical about it: if your requirements are still forming, prioritise overlapping working hours. If they are well documented and stable, a wider gap is manageable and the cost difference may be real. Ask where the team actually sits rather than where the company is registered.
The question that matters most
Ask what they would do if the project ran into trouble — a missed date, a requirement that turns out to be impossible, a budget under pressure. The answer reveals how they think about risk and about you. Suppliers who have delivered for years have good answers because they have been there. Suppliers who have not will tell you it does not happen to them.
This is the kind of work we do. If it is relevant to something you are planning, our custom software page covers how we approach it, or you can describe the project and we will tell you what we think.