Most guidance on choosing a development partner offers the same advice: check the portfolio, read the reviews, make sure communication is good. All true, all useless, because every supplier passes that test. Firms that go wrong rarely look bad at the proposal stage. They look fine, and the problems surface in month three.
Here is what we would check if we were the ones hiring, including the questions that are uncomfortable to ask.
First, work out what you actually need
These get lumped together as “agencies” and behave very differently.
A staffing firm supplies developers who work under your management. You direct the work and own the outcome. Sensible if you already have a technical lead and a clear plan, expensive to learn on if you do not.
A delivery team takes responsibility for shipping something that works: analysis, architecture, build, testing, release. You stay accountable for the business decisions rather than for running the team day to day.
A product partner also contributes to what should be built, not only how. Worth paying for when the problem is understood but the solution is not.
A lot of dissatisfaction comes from buying the first and expecting the third. If you want a team that argues with your scope, say so in the brief, then check whether their proposal actually does any arguing.
The proposal is a work sample
Read it as one.
Did they ask anything before writing it? A detailed quote produced from a two-paragraph brief without a single clarifying question means they have either built this exact thing before, which they should say, or they are guessing.
Did they tell you anything you did not want to hear? If your brief has a problem, and most do, a supplier who spots it and stays quiet at the proposal stage will also stay quiet in month four.
Questions worth asking, and what the answers mean
Who will actually do the work?
Ask for named people, their seniority, and how much of their week you get. The common failure is meeting the principals during the sale and being handed juniors afterward. Ask directly whether anyone in the room will be on the project, and whether any of it is subcontracted.
What happens when the estimate turns out to be wrong?
Estimates are sometimes wrong, and that is not the interesting part. What happens next is. You want a concrete mechanism: when it becomes apparent, who gets told, what the options are. “We are very accurate” is not an answer, and given that large IT projects run 45% over budget on average, it is not a credible one either.
Tell me about a project that went badly.
The most informative question available to you. Everyone has one. You are listening for whether they can describe what went wrong without blaming the client entirely, and what they changed afterward. A supplier who has never had a difficult project has either not done many or is not being straight with you.
What do we own at the end?
Source code in a repository you control, infrastructure in your accounts, documentation good enough for another team to take over, and unambiguous IP ownership. Get it in writing before signing. It is far harder to negotiate once a relationship has soured, which is precisely when you need it.
How do you handle the first month after launch?
Real users find what testing missed. If nobody has planned for the stabilisation period, it gets absorbed by whoever has slack, which is usually nobody, and it comes out of the next project’s budget.
Check the work, not the pitch
References the supplier chose for you are lightly useful. Better signals:
- Ask to see code. Even if you cannot read it, have your own developer or a contractor spend an hour with a sample. Tests, comments and consistency are visible fast.
- Ask what happened after the case study ended. Case studies stop at launch. Ask whether the client still uses it, whether it was extended, and who maintains it now.
- Ask for a reference on a project that did not go smoothly. The answer, or the refusal, tells you something either way.
- Look at public work. For a software company, a code presence and independent review profiles are easy to check and hard to fake.
- The estimate is dramatically lower than everyone else’s. They have either misunderstood the scope or intend to recover margin through change requests.
- They agree to everything. A team with real experience of your problem will have opinions, including inconvenient ones.
- Pressure to sign quickly. Discounts that expire are a sales tactic, not a commercial reality.
- They cannot explain their process without jargon. If “agile” is a label rather than a description, ask what happens in a typical two-week period.
- Vagueness about ownership or hosting. Any hesitation about you owning the code and the infrastructure is a serious problem.
- No questions about your existing systems. Integrations are the most common source of overrun. A supplier not asking has not thought about it.
De-risk the decision itself
You do not have to commit a full budget to a supplier you have met twice. Buy a small piece of work first: a discovery phase, a technical assessment, or a narrow first slice of the build. It should be fixed-price, time-boxed, and produce something useful on its own, such as a scope, an architecture and an estimate with stated assumptions.
A paid trial tells you more in three weeks than any number of sales meetings. You see how they communicate under real conditions, whether they hit dates, how they handle a question nobody anticipated, and whether their written work is clear. If it goes badly you have lost a small amount of money rather than a year.
Any supplier confident in their work will agree to this. Reluctance is itself an answer, and it is the cheapest piece of information you will get in the whole process.
How we work, so you can compare
We quote in two stages: a short fixed-price discovery that produces scope, an integration map and architecture, then a build priced against that. Work runs in two to three week releases so progress stays visible, and you own the code and infrastructure throughout.
Our case studies show completed work, what custom software actually costs sets out where budget goes, and why projects run over budget covers the warning signs to watch for in any supplier, including us.
If you are running a selection process, send us the brief. We will tell you what we think is missing from it, which is useful whether or not you end up working with us.
Common questions
What should I ask a software development company before hiring them?
Who specifically will do the work and at what seniority, what happens when the estimate turns out to be wrong, a story about a project that went badly, what you own at the end, and how the first month after launch is handled. The answers to those five separate suppliers more reliably than any portfolio.
Should I pick the cheapest quote?
A quote well below the others usually means the scope was misunderstood or the margin will be recovered through change requests. Compare what each quote excludes and what assumptions it names, not the headline figure.
How can I test a supplier before committing a full budget?
Buy a small fixed-price, time-boxed piece of work first, such as a discovery phase or a narrow slice of the build, and make sure its output stands alone and could be handed to another supplier. Three weeks of real work reveals more than any number of sales meetings.
Sources
- McKinsey & Company with the University of Oxford, Delivering large-scale IT projects on time, on budget, and on value. More than 5,400 IT projects: 45% average cost overrun, 56% less value than predicted.
Figures were current at the time of writing (September 2026).
