Most people choosing a development partner are doing it for the first time, against suppliers who do it every week. That asymmetry, rather than any shortage of good engineers, is why so many of these decisions go badly.
You cannot assess code quality before the code exists. What you can assess is how a supplier thinks, how they behave when they disagree with you, and whether their commercial incentives point the same way as yours.
Start With the Problem, Not the Spec
A brief that specifies a solution invites quotes on the solution. If you hand five suppliers a feature list, you will get five prices for that feature list and no opinion on whether the list is right.
Describe the problem instead: who has it, what they do today, what it costs you, and how you will know it is solved. A supplier worth hiring will come back with questions and, sometimes, with a different shape of answer than the one you asked for.
The ones who simply price your list without challenging anything are telling you something. Either they did not read it closely, or they are content to build whatever is specified and let the outcome be your problem.
Questions Worth Asking
Who will actually write the code, and can I meet them? Agencies frequently sell with senior people and staff with juniors. This is not automatically wrong, but you should know the real composition of the team and who is accountable day to day.
What happens when we disagree about scope? The answer reveals the commercial model. Listen for whether change is treated as a normal part of building software or as a billing event.
Show me something you built that went wrong, and what you did. Everyone has one. A supplier who claims otherwise is either inexperienced or managing you.
Who owns the code, the repositories and the infrastructure accounts? The correct answer is you, from day one, in your own accounts. Anything else creates a dependency that is expensive to unwind later.
What does handover look like if we part ways in six months? A partner confident in their work will have a straightforward answer. Vagueness here is a warning.
How to Read a Proposal
Compare the assumptions, not the totals. Two quotes that differ by a factor of three usually differ in what they have assumed about testing, infrastructure, data migration, browser and device support, accessibility, and who writes the content. The cheap one has often assumed those away rather than solved them more efficiently.
Look for the word "discovery" and check whether it is a real, separately priced piece of work with its own deliverable, or a line item that quietly means "we will find out later at your expense".
Check whether the estimate has a shape. A single number for a six-month build is not an estimate, it is a wish. Phased numbers with stated confidence levels, or a range with the drivers named, reflect how software is actually estimated.
Be wary of a proposal that contains no risks section. Every real project has three or four things that could go wrong, and a supplier who has thought about yours will name them.
Warning Signs
Certainty too early. A supplier who can price a complex system precisely after a one-hour call has either built exactly this before, or is guessing and will recover the difference through change requests.
A team that agrees with everything. You are buying judgement as much as hands. If nobody ever pushes back on your thinking, you are paying for a typing service.
No named technical contact. If every conversation runs through an account manager and you never speak to an engineer, problems will reach you late and pre-interpreted.
Reluctance to work in your repositories or your cloud accounts. Occasionally there are real reasons. Usually it is leverage.
Portfolio work that cannot be attributed. Logos on a page are not evidence. Ask which specific parts they built, when, and whether the client will speak to you.
Location, Time Zones and What They Actually Cost
The real cost of distance is not the hourly rate, it is the length of the feedback loop. A question that takes eight hours to answer turns a two-day task into a two-week one, and no rate card shows that.
Overlap hours matter more than the country. Four hours of genuine overlap with your working day is usually enough for a well-run team. Zero overlap requires a level of written discipline that most organisations do not have.
For work involving personal data, where the team sits also has legal consequences. If you are subject to GDPR, processing outside the European Economic Area needs a lawful transfer mechanism, and that is a question for the contract, not an afterthought.
De-risk It With a Paid Trial
The single most useful thing you can do is buy a small piece of real work before committing to the whole programme. Two to four weeks, paid at full rate, producing something you would have needed anyway: a technical discovery, a prototype of the hardest part, an integration spike.
You learn what no reference call will tell you. How they write things down. Whether estimates hold. What they do on the day something slips. Whether you enjoy the meetings.
It also gives you a clean exit. Ending a four-week engagement is a normal business decision. Ending a nine-month one is a crisis.
Thinking of hiring a development team?
Tell us what you are trying to do and we will tell you honestly whether we are the right people for it.
Get in touch