Every software development agency’s website says the same thing: experienced team, proven process, client-focused delivery. None of it tells you anything, because none of it is falsifiable. The businesses that end up disappointed with a development partner rarely picked a bad-sounding agency, they picked a good-sounding one and never tested whether the substance behind the pitch was real.
Key Takeaways
- Portfolio work and client testimonials are marketing artefacts, not evidence; ask to speak to a former client directly and ask what went wrong, not just what went right.
- A development partner’s technical capability matters less than whether their process fits how your organisation actually makes decisions, since most project friction is about communication, not code.
- Fixed-price quotes given before any scoping work are a red flag, not a sign of confidence, because they imply the agency already knows your requirements better than you do.
- Ownership of code, documentation and infrastructure access should be settled contractually before work starts, not negotiated after the relationship has already gone wrong.
- The right technical fit still fails without cultural fit: how a partner handles disagreement and delay tells you more than how they handle the parts that go smoothly.
The gap between a convincing pitch and a capable delivery team is where most procurement decisions actually go wrong, and it rarely shows up until the project is already underway.
Look Past the Portfolio
A portfolio shows finished work, not how it was built or what compromises were made to get there. It is reasonable evidence that an agency can produce something, but it says very little about how they behaved under pressure, how they handled a client who changed their mind halfway through, or whether the finished product actually performed once it launched.
The British Computer Society’s guidance on selecting a technology partner puts weight on asking for references from clients whose projects are similar in scale and complexity to your own, then actually speaking to them rather than treating a written testimonial as sufficient. A candid conversation with a past client, particularly one asked what they would do differently, surfaces far more than a case study written by the agency’s own marketing team.
A business meeting with two people shaking hands across a table
Ask About Process, Not Just Output
The National Audit Office’s 2025 review of government’s approach to technology suppliers found that procurement conversations too often focus on price and delivery speed while under-scrutinising a supplier’s actual process for managing scope changes, handling disagreements and reporting progress, precisely the gaps that surface once a project is already underway. A team that writes excellent code but communicates poorly about delays will cause more damage to a project than a slightly less polished team that is transparent from the start.
Ask specifically how the partner handles a change of mind. Every project has one. The answer reveals whether they see scope as fixed and sacred, which usually means expensive change requests later, or whether they build in room for iteration from the outset.
The Fixed-Price Trap
A quote delivered before any scoping conversation has happened is one of the clearest warning signs in software procurement. It means one of two things: the agency has a template estimate they apply regardless of your actual requirements, or they intend to make the number work by cutting corners once the contract is signed.
CIO’s 2023 guidance on selecting project management and delivery software makes a related point about vendor evaluation more broadly: a vendor who understands your specific requirements well enough to give a considered estimate is a stronger signal than one who is fastest to quote a number. Speed at the quoting stage is not the same as speed at delivery, and the two are sometimes inversely related.
A fixed-price quote given before any scoping work has happened tells you the agency already thinks it knows your requirements better than you do.
A discovery or scoping stage before a firm quote is not a delay tactic, it is the mechanism by which a genuine estimate becomes possible. Agencies that resist this step are usually protecting a sales process, not your budget.
An overhead view of hands typing on a laptop keyboard beside a mug, glasses and notebook
Settle Ownership Before You Start
Who owns the code, the documentation, the infrastructure accounts and the domain once the project ends is a question that should be answered in the contract, not discovered later when the relationship has soured. The ISO/IEC/IEEE standard covering documentation of software life-cycle information items exists precisely because handover documentation, source access and configuration details are where projects fall apart when a client tries to move to a new provider or bring development in-house.
A partner confident in their own work has no reason to make code or infrastructure access difficult to transfer. Reluctance on this point, even if framed as a technical limitation, is worth pressing on before signing anything.
Cultural Fit Still Decides the Outcome
Two technically capable teams can produce very different experiences for the client depending on how they handle the moments that do not go to plan. A delay disclosed early, with a clear explanation and a revised plan, builds trust even though nobody likes hearing about delays. The same delay discovered by the client because a deadline was silently missed does lasting damage regardless of how good the eventual output is.
Development partners that work in regulated sectors, health technology among them, tend to be unusually disciplined about this kind of transparency because the cost of a late or wrong delivery is higher than a missed marketing deadline. It’s part of why visit their site is worth doing before shortlisting any partner: reading how an agency talks about its own past projects, including the constraints it worked within, tells you more about their honesty than any pitch deck will.
None of this is about finding a partner who never has problems. Every non-trivial software project hits at least one unexpected snag, whether that’s a third-party API that behaves differently to its documentation or a requirement that turns out to be more complicated once work actually starts. What separates a good partner from a risky one is not the absence of these moments but how quickly they surface them and how clearly they explain the options for dealing with them.
Frequently Asked Questions
How many development partners should I shortlist before deciding?
Three is usually enough to compare approach and pricing without the process becoming unmanageable. More than that tends to produce diminishing returns and a longer decision cycle without meaningfully better information.
Should I choose the cheapest quote?
Not without understanding why it is cheaper. A lower price sometimes reflects genuine efficiency, but it can also reflect a smaller team, less senior staff, or scope that will expand through change requests once work begins.
What questions expose a weak development partner fastest?
Ask what went wrong on their last three projects and how they handled it. An agency that can only describe successes is either inexperienced or unwilling to be candid, both of which are useful things to know before signing a contract.
Is a written contract enough to protect code ownership?
A contract that explicitly states IP ownership, handover obligations and access to infrastructure accounts is necessary, but it should be checked against what the agency actually delivers at each milestone, not assumed to be self-enforcing.
How much should a discovery phase cost before the main build begins?
It varies with project complexity, but a discovery stage is typically a small fraction of total project cost. Treat a quote that skips this stage entirely with more suspicion than one that includes it as a distinct, priced piece of work.