How to Choose a Development Partner
The evaluation framework we would want a buyer to run — including how to run it on us. What to ask, what the answers mean, and which signals are worth nothing.
Contents8 sections
Choosing an engineering partner is a decision made with almost no usable information. You cannot evaluate the code, the references are curated, and every proposal says the same nine things. What follows is the framework we would want a buyer to use — partly because it is the honest way to choose, and partly because a buyer who evaluates properly is a better client than one who picks on price.
What the outcome data looks like
- 31%
- IT projects that succeed outright
- 45%
- Large IT projects that run over budget
- 42%
- Name specialised talent as the top outsourcing driver
Standish CHAOS; 50% challenged, 19% failed. Definitions have shifted between editions
McKinsey with Oxford — and they deliver 56% less value than predicted
cost now 34%, was 70%
Deloitte Global Outsourcing Survey
Which signals are actually worth something?
Sort every signal by two things: how hard it is to fake, and how much it tells you about your specific project. Most of what appears in a pitch scores badly on both.
| Signal | Worth | Why |
|---|---|---|
| They push back on your scope | High | It costs them the easy sale. Almost nothing else in a sales process has that property |
| They can describe a failure and the fix | High | Unrehearsed, specific, and impossible to fake convincingly |
| Named delivery team with seniority, before signing | High | "Senior-led" in a proposal and a senior on your standup are different claims |
| A reference whose project went badly | High | Everyone has one. Only some will put you on the phone with it |
| Third-party reviews with detail | Medium | Hard to fabricate at volume, but skewed toward clients who stayed |
| Portfolio and case studies | Low | Selected, polished, and frequently the work of people who have since left |
| Hourly rate | Low | Easy to compare, easy to negotiate, and a poor predictor of total cost |
| Awards, badges, partner tiers | Very low | Most are paid, applied for, or both |
What should you ask on the first call?
Ten questions. The point of each is not the answer so much as whether a specific answer exists — vagueness on any of these is itself the finding, and you will hear the difference immediately.
The ten, in the order worth asking them
- What do you think is wrong with my brief? Silence here is the answer to several later questions.
- Who, by name, will be on this day to day, and what is their seniority?
- What exactly is fixed in the fixed price, and what triggers a change order?
- What is your median time from kickoff to something real users can touch? Not to a demo.
- Tell me about a project that went badly and what you changed afterwards.
- Who owns the code, and when does ownership transfer? Get the clause, not the reassurance.
- What happens in month four? Who maintains it and at what monthly cost.
- What would make you turn this project down?
- Which parts of this will you subcontract?
- Can I speak to a client who is no longer working with you?
How do you read a quote?
Two quotes are almost never comparable, because the expensive one is usually describing more work rather than charging more for the same work. Before comparing totals, normalise them: make each quote say what is included, and the gap generally explains itself. What an MVP actually costs breaks our own line items out for comparison.
Normalise on these before you compare a single number
- Design — included, or a separate engagement you have not budgeted?
- Testing — what kind, and is it in the estimate or listed as optional?
- Third-party integrations — named individually, or bundled behind one line?
- Deployment and environments — who sets them up, who owns the accounts?
- Project management — a line item, a percentage, or invisible and therefore in the rate?
- Post-launch — what is covered, for how long, and what does it cost after that?
- Change orders — the mechanism and the rate, in writing
Agency, freelancer, or augmentation?
Three different products, routinely compared as though they were one. The deciding question is not budget. It is where technical direction comes from, and whether you have the capacity to supply it.
| Option | Right when | What it demands of you |
|---|---|---|
| Agency | You need an outcome delivered and do not have someone to direct it | A clear definition of done, and the willingness to be argued with |
| Freelancer | The scope is small, well-defined, and you can judge the work | Your own technical judgement, and a plan for the bus factor of one |
| Staff augmentation | You have an engineering function and need more of it | Onboarding capacity, code review, and someone owning their backlog |
What are the red flags?
- A quote before a conversation. A number produced without understanding your integrations and permission model is a guess with confidence attached.
- No named team. If seniority cannot be confirmed before signing, it will not be confirmed after.
- Every answer is yes. A partner with no boundaries has no opinion, and you are buying the opinion.
- Pressure on the timeline of the decision. A discount that expires on Friday is a sales tactic, not a pricing structure.
- Ambiguity about IP. Assignment on payment, in the master agreement. Reputable firms have it as standard, which is why negotiation here is informative.
- No answer for month four. The handover is where most of the cost of a bad choice actually lands.
Now run it on us
A framework that conveniently selects its author is not a framework. Here is Codeable — an AI-powered software development agency in Westford, MA and Lahore — against the same questions, including where the honest answer is unhelpful to us.
| The question | Our answer |
|---|---|
| Who is on the team, by name? | Named before signing. Fifteen people total, which is also the constraint — quarterly capacity is genuinely limited |
| What is fixed in the fixed price? | The agreed scope, over a published 30–90 day window. Change orders are triggered by scope additions, and the mechanism is in the contract |
| What would you turn down? | Sub-$5,000 scopes, one-off bug fixes without an audit first, games and real-time graphics, and anything needing regulated-industry accreditation we do not hold |
| What do you subcontract? | Nothing on the engineering side. We have no standalone cloud or DevOps practice and no HubSpot case study — if that is the engagement, we are the wrong call |
| Where are you weakest? | Scale and design. Fifteen people cannot staff thirty engineers next quarter, and a design-led studio will produce a better-looking result than we will |
| Your reviews? | 5.0 on Clutch, and thin — a small number of reviews. Read that as "nothing has gone publicly wrong", not as a large sample |
Common questions
How many agencies should I talk to?
Three is usually enough to calibrate and few enough to run properly. The value of a fourth conversation is lower than the value of asking the first three harder questions, and a long shortlist tends to push the decision back onto price because price is the only thing that stays comparable across many quotes.
Should I pay for a discovery or scoping phase?
Often yes, and it is frequently the best money in the project. A paid scope produces a document you own and can take to anyone, which also makes the rest of the quotes comparable. Be clear up front that the output is yours regardless of who builds it.
How much should I care about where the team is?
Less than about overlap hours, which is a property of the vendor's working agreement rather than of a country. Ask for the specific hours the senior engineers work, not the hours the company is open. Our offshore shortlist goes through the rate and overlap trade-offs in detail.
What if I'm not technical enough to evaluate the answers?
Most of the questions above are deliberately not technical — they are about specificity, boundaries and what happens when things go wrong, and you can judge all three. For the genuinely technical parts, an independent hour from an engineer you trust is cheap insurance against a six-figure decision.
Is a bigger agency safer?
Safer against disappearing, yes. Not necessarily safer against the more common outcome, which is delivery that is slower and less attentive than the pitch implied. Scale buys continuity and costs you seniority-per-project; work out which risk you are actually exposed to.
The short of it
Ask what they would turn down, who is on the team by name, and what happens in month four. Normalise the quotes before comparing them. Then pick the partner who argued with your brief — the one who agreed with all of it is the expensive option, whatever the number says.
