Choosing a development partner is a high-consequence decision made with limited information. Every vendor's website says the same things - experienced team, agile process, client-focused delivery - and none of it is falsifiable from the outside. The difference between a good partner and an expensive mistake usually only becomes visible three months in.
What follows is a practical way to get that signal earlier: what to verify, what to ask, and what should end the conversation.
Start with your own brief
Before contacting anyone, write down the business problem, who the users are, what success looks like in measurable terms, your realistic budget range, and any hard constraints such as compliance requirements or systems you must integrate with.
This matters for two reasons. It lets every vendor quote against the same thing, which is the only way comparison works. And a vendor's response to a clear brief tells you a great deal - a good one will push back on assumptions and ask uncomfortable questions, while a weak one will simply agree with everything and quote.
Verify domain experience, not just years in business
"Twenty years of experience" is close to meaningless if none of it is in your problem space. What you want to know is whether they have solved a structurally similar problem before.
Ask for two or three case studies that resemble your project in domain, complexity or integration profile, and then ask specific follow-up questions: what went wrong on that project, what did you change as a result, how long did it actually take versus the original estimate. Vendors who have genuinely delivered will answer these easily. Vendors describing aspirational work will get vague.
Regulated industries deserve extra scrutiny. Healthcare, financial services and insurance carry compliance obligations that are expensive to retrofit. A team that has never built under HIPAA or PCI DSS will learn on your budget and your timeline.
Insist on meeting the engineers
This is the highest-value filter available to you. Many firms sell with senior people and deliver with juniors. Ask to speak with the specific tech lead and developers who would be assigned to your project, and ask them technical questions about your problem.
You are not testing whether they know a particular framework. You are testing whether they can reason about trade-offs - why this database over that one, how they would handle a failure in your critical path, what they would do differently if your load were ten times higher. Engineers who think in trade-offs build maintainable systems. Engineers who only recite technology names do not.
If a vendor will not put you in front of the delivery team before you sign, treat that as an answer.
Interrogate the process
Ask them to walk you through how work actually flows, and listen for specifics:
- Requirements - how do they capture and sign off scope, and what happens when it changes mid-project?
- Sprints and visibility - how often will you see working software rather than a status report?
- Code quality - is there mandatory code review? What are the merge rules?
- Testing - what mix of automated and manual testing, and what coverage do they target?
- Deployment - is there a CI/CD pipeline, or are releases manual?
- Communication - who is your single point of contact, on what channels, and what overlap do you have with their working hours?
The most reliable signal here is testing. A team that treats QA as a phase at the end, or as something the client does, will ship defects into production and bill you to fix them.
Get the commercial terms right
Several contract points are worth more than a discount:
IP ownership. The contract must state unambiguously that you own the source code, designs and documentation on payment. Some agreements quietly retain rights over "frameworks" or "reusable components" that turn out to be central to your product.
Repository access. You should have access to the code repository from day one, not at handover. If the code only appears at the end, you cannot verify quality and you have no leverage.
Exit terms. Know what happens if you want to stop. A reasonable contract includes a notice period, a documented handover, and no hostage-taking of credentials or infrastructure.
Support terms. Establish what happens after launch - what counts as a warranty bug fix versus billable work, response times for critical issues, and the cost of an ongoing support arrangement.
Red flags
Any one of these should slow you down considerably:
- A firm price quoted before anyone has understood the requirements in detail
- Refusal to let you meet the delivery team
- No written testing process, or QA described as optional
- Unwillingness to provide references you can contact directly
- Vague or client-unfavourable IP terms
- Urgency and discount pressure to sign this week
- A proposal with no stated assumptions or exclusions
- Claiming deep expertise in every technology that exists
That last one is worth dwelling on. Nobody is genuinely expert in everything. A partner who tells you a particular approach is outside their strength is giving you useful information and demonstrating honesty at their own commercial cost.
Compare proposals on the same basis
When quotes come back, normalise them before comparing. For each one, write down what was included, what was excluded, what assumptions were made about scope, and what role mix and seniority is proposed. Then compare total cost of the same scope.
A quote that looks 30 percent cheaper often excludes QA, project management, deployment or a discovery phase. That cost has not vanished - it has moved to you, usually at a worse moment.
De-risk with a small first engagement
The most effective thing you can do is not choose perfectly, but choose reversibly. Start with a paid discovery phase or a small, self-contained module. Within a few weeks you will learn how they communicate, whether they hit dates, what their code looks like and whether they raise problems early or hide them.
That evidence is worth more than any reference call. And if it goes badly, you have spent a small amount to avoid a large mistake.
If you are working through this evaluation now, get in touch - we are happy to answer these questions about our own team, including the awkward ones.