Nearly every guide to choosing a development partner is written by one, and the tell is that each criterion happens to describe the author. So here is ours with the disqualifiers included: the cases where you should not hire a firm like us are set out below, in full. The single most useful move is to match the shape of the partner to the shape of the problem, because most selection failures are a mismatch rather than a competence issue. After that, the questions that separate firms are about who actually writes the code, how change is priced, and whether you can leave.
We are a software development company. You are reading our advice on how to pick one. You should weigh that accordingly, and the most honest thing we can do is make the article useful even to someone who ends up hiring somebody else.
So this includes the cases where we are the wrong answer, stated plainly rather than buried.
First, match the shape
Most disappointing engagements are not caused by a bad firm. They are caused by hiring a firm whose business model does not fit the problem. These are genuinely different businesses:
Work out which row you are in before you shortlist. It is a ten-minute conversation that saves a month of mismatched proposals.
When not to hire a firm like ours
Stated directly, because a selection guide without them is marketing:
- You need scale, fast. Dozens of engineers inside a quarter is a staffing firm's business. A boutique that says yes to this is either subcontracting or about to hire strangers on your budget.
- The work genuinely needs daily physical presence. Hardware in a lab, a trading floor, a factory commissioning. Some things do not work over a call, and claiming otherwise helps nobody.
- You need round-the-clock coverage from day one. That is a different operating model with a rota and a support tier behind it, not a development team working extra hours.
- A specific certification or accreditation is mandatory and the firm does not hold it. Ask for the certificate, not the claim, and do it early — this one ends conversations late and expensively.
- Lowest rate is the actual criterion. A small senior team will not be the cheapest quote. If price is the deciding factor, be honest about that and choose accordingly; just go in knowing what is usually traded away.
- You need someone to take over an undocumented system, with no access to the people who built it, against a hard external deadline. This is high-risk with any partner. It can be done, but anyone quoting it confidently and cheaply has not understood it.
The questions that actually separate firms
Once the shape fits, most differentiation claims converge into the same paragraph. These questions do not:
Who writes the code?
Ask to meet the engineers who would be assigned, by name, before signing. Ask what they are working on now and when they would roll off.
The gap between the team that sells and the team that delivers is the most reliable disappointment in this market. A firm that will only put account managers in front of you, or cannot name your team, has answered the question. Named people in the statement of work is a reasonable thing to ask for.
How is change handled?
More useful than the fixed-price versus time-and-materials debate. Fixed-price fits genuinely defined work, and its premium is the price of everything undefined. Time and materials fits discovery, but only with real transparency and the ability to stop.
Either way, ask to see the change process in writing — who can request, who prices it, how long it takes, what happens to the timeline. That process is what you will live with daily. If you are still at the specification stage, writing an RFP that gets useful answers is the cheapest way to make proposals comparable.
What happens when they disagree with you?
Ask for a time they told a client an idea was wrong, and how it went.
A partner who never pushes back is a contractor, and you will get precisely what you specified including the mistakes. The willingness to say "that will not work, here is why" is most of the difference between a supplier and a partner, and it is observable during the sales process if you look for it.
Can you leave?
Negotiated hard on rate, signed away entirely on exit, is the standard own goal. Settle before signing:
- IP assignment in writing, covering everything produced.
- Your accounts from day one — repositories, cloud, domains, app-store listings in your organisation, not theirs. Not "transferred at handover".
- Documentation as a deliverable, with acceptance criteria, not a goodwill promise.
- A defined exit process: notice period, transition support, and what handover includes.
- Data handling, especially across borders. For EU and UK clients this starts before the contract — see GDPR when you outsource development to India.
References you picked
Reference lists are curated. Ask for a client in your sector at your size, a former client rather than only current ones, and a project that went badly.
Every firm has one. A partner who can describe what went wrong, what they did, and what they changed afterwards is giving you far more signal than a polished success story — and the inability to produce one is itself an answer.
A reasonable process
- Decide your row in the table above. Eliminate the mismatches.
- Write down how success will be measured before talking to anyone. If that is hard, the scope is not ready, and no partner will fix that for you.
- Shortlist three. More produces noise; one removes your leverage.
- Meet the engineers, not only the sales team.
- Run a small paid piece of real work before the large commitment. It is the only evaluation that reliably predicts the engagement, and a firm that refuses is telling you something.
- Settle the exit terms while you still have leverage, which is now.
None of this guarantees a good outcome. It does remove the failures that were predictable from the start, which is most of them.
Questions we get asked
What should I check first?
Whether the firm's shape matches your problem's shape. Staffing firms, boutiques and product studios are different businesses solving different problems well, and most failures are mismatches rather than competence issues. That one decision eliminates most of the market.
How do I know the people who pitched will do the work?
Ask to meet the assigned engineers by name before signing, and ask when they roll off current work. The sell-team/deliver-team gap is this market's most common disappointment. Named people in the SOW is a fair request.
Fixed-price or time and materials?
Fixed-price suits genuinely defined work and prices the risk of everything undefined; T&M suits discovery, with transparency and the ability to stop. The better question is how change is handled — ask to see that process in writing.
How should I check references?
Pick them yourself rather than taking the list offered, include a former client, and ask for a project that went badly. How a firm describes a failure — and what it changed afterwards — carries far more signal than a success story.
Which contract terms matter most?
The ones that let you leave: written IP assignment, your ownership of repos, cloud accounts and domains from day one, documentation as a deliverable, and a defined exit and transition process. Rate is negotiated hard; exit is signed away. The second costs more.
When should I not hire an offshore boutique?
When you need many engineers inside a quarter, when the work truly needs daily on-site presence, when you need 24/7 coverage from day one, when a certification is mandatory and the firm lacks it, or when lowest rate is your real criterion. We would not be the right answer in any of those.
If after all that your row is the second one — a small senior team owning outcomes, with direct access to the people writing the code — that is how we work, and the fastest way to test it is a small paid piece of real work rather than a longer pitch.