How to Choose a Software Development Partner (From the Other Side of the Table)

Why This Decision Goes Wrong So Often

Most failed software projects were not killed by a technical problem. They were killed by a mismatch that existed before a line of code was written — the wrong partner, the wrong contract shape, or the wrong assumptions about who was responsible for what.

The uncomfortable part is that the failure is usually visible in the sales process, if you know what to look for. A supplier who agrees to everything, quotes a fixed price for a vague brief, and promises a timeline that assumes nothing goes wrong is not being confident. They are being optimistic in a way that will become your problem in month four.

This is a practical guide to choosing a development partner, written from the supplier side of the table but honestly. We have won projects we should have turned down and turned down projects we could have won, and the pattern in both directions is consistent.

Know Which of Three Things You Are Buying

The word "agency" covers three quite different commercial models, and buyers frequently think they are purchasing one while actually purchasing another.

• Staff augmentation. You are renting developers who work under your direction. You provide the product management, the priorities, and the quality bar. This is cheapest per hour and most expensive in your own time. It works when you have internal technical leadership and lack capacity.
• Project delivery. You are buying an outcome. The supplier provides the team, the process, and the accountability for delivering a defined scope. It costs more per hour and less of your attention. This is what most non-technical businesses actually need.
• Product partnership. An ongoing relationship where the supplier holds long-term responsibility for a product's evolution, not just a scope. Suits businesses whose software is the business.

Buying staff augmentation while expecting project delivery is the most common and most damaging mismatch. You get exactly what you asked for — developers who do what they are told — and then discover nobody was making the decisions you assumed someone was making.

Decide which you are buying, say so explicitly, and price accordingly.

Onshore, Offshore, and the Question That Actually Matters

The geography conversation usually starts with day rates and stops there. Rates differ substantially — we broke down realistic numbers in our comparison of development costs across the UK, Pakistan, and the UAE — but rate is only one input.

What actually determines whether a distributed arrangement works:

• Overlap hours. Four hours of genuine overlap is workable. One hour is not, regardless of anyone's good intentions. Ask specifically which hours the team works in your time zone.
• Communication ownership. Is there a named person accountable for the project who communicates in your language and understands your business, or are you talking to a rotating cast of developers?
• Time zone as an advantage or a tax. Handover-based work can genuinely benefit from time differences. Collaborative product work suffers from them.
• Contractual and legal reality. Which jurisdiction governs the contract, where does your data sit, and what happens if the relationship ends badly.

The honest position is that a well-run distributed team with strong overlap and clear ownership outperforms a poorly run local one, and a poorly run distributed team is the worst of all worlds. Geography is not the variable, structure is.

What to Look for in a Supplier

The signals that correlate with projects going well, in our experience of both delivering and inheriting them:

• They push back during the sales process. A supplier who questions your assumptions, tells you a feature is not worth building, or suggests a smaller first phase is demonstrating exactly the judgment you are paying for.
• They have shipped in your domain, or something structurally similar. Domain knowledge is not everything, but a team that has already learned where the edge cases hide in booking, payments, or delivery will not learn them on your budget.
• They can explain their process without jargon. Ask how work gets from idea to production and listen for whether the answer describes something real.
• They talk about maintenance and handover unprompted. Suppliers who intend a long relationship discuss what happens after launch. Ones who intend a transaction do not.
• References you can actually speak to, including a project that went badly. Every supplier has one. The ones worth hiring will discuss it.
• Their own code and process standards. Ask about testing, code review, and deployment. The answers reveal a great deal quickly.

The Warning Signs

Equally, the signals that reliably precede trouble:

• A fixed price for a vague brief. Nobody can price what has not been specified. A supplier who does either padded the number heavily or will recover the difference through change requests and corner-cutting.
• Agreement with everything. If a supplier has no opinions about your requirements, they either have no experience or no intention of engaging with the substance.
• Timelines with no slack. A plan where every task takes exactly as long as estimated and nothing goes wrong is a plan that has already failed.
• No named team. "We will assign developers" means you do not know who is building your product.
• Ambiguity about code ownership. This should be unambiguous and in writing before anything starts.
• Portfolio work you cannot verify. Ask for live URLs, not screenshots.
• Pressure to sign quickly. Discounts that expire on Friday belong in retail, not professional services.

Get the Contract Shape Right

The commercial structure determines behaviour more than any clause in it.

• Fixed price works when the scope is genuinely fixed and well specified. It transfers risk to the supplier, who prices that risk in. Every change becomes a negotiation, which is fine if changes are rare and corrosive if they are not.
• Time and materials works when the destination is understood but the route is not. It requires trust and visibility, and it fails badly with a supplier you cannot see clearly.
• Capped time and materials, with an agreed ceiling and shared visibility, is where most healthy projects land. You get flexibility without an unbounded commitment.
• Phased fixed price — a fixed price for a well-defined discovery phase, then a fixed price for a specified build — is the structure we recommend most often. It lets both sides price the build against a real specification rather than a hope.

Whatever the shape, insist on these terms: you own the code and all intellectual property outright, the code lives in a repository you control from day one, deployment credentials and infrastructure accounts are in your name, and there is a defined handover deliverable. Suppliers who resist any of these are protecting an ability to hold your product hostage, and that is disqualifying regardless of how good their work is.

Discovery Is Not a Sales Tactic

A paid discovery phase — typically one to three weeks producing a specification, technical approach, wireframes, and a credible estimate — is often perceived as a way for agencies to charge for a proposal. Sometimes it is. Done properly it is the highest-return spend on the whole project.

What a good discovery produces:

• A written specification detailed enough that a different supplier could build from it.
• The technical approach and the significant architectural decisions, with reasoning.
• Wireframes or prototypes of the primary flows.
• An estimate with ranges and stated assumptions rather than a single number.
• An explicit list of risks and unknowns.
• A phasing plan identifying what genuinely must be in version one.

The test of whether discovery was worth paying for is simple: you should be able to take the output to a different supplier and get a comparable quote. If you cannot, you bought a sales document.

The reason this matters commercially is that the alternative — building from a vague brief — means the specification gets written during development, in fragments, by people making assumptions. That is where budget overruns come from, almost every time.

Scope Version One Ruthlessly

The single most reliable predictor of a project going well is a small first release.

Almost every brief we receive contains at least 40% of features that could wait. Admin tooling that could be a database query for the first three months. Reporting that could be a spreadsheet export. Integrations that could be manual until volume justifies automating them. A second user role that has no users yet.

The argument for cutting is not just cost. It is that everything you build before real users touch the product is built on assumptions, and a meaningful proportion of those assumptions will be wrong. Shipping something smaller sooner converts assumptions into knowledge, and the second phase is then built on evidence.

A useful exercise: for each feature, ask what happens if it is not there on launch day. If the answer is "someone does it manually" or "we tell customers it is coming", it is a phase two feature.

Comparing Quotes That Are Not Comparable

Three quotes arrive at £18,000, £46,000, and £95,000 for what looks like the same brief. The instinct is to assume the middle one is sensible and the cheapest is a bargain. Usually all three are answering different questions.

Normalise them before comparing:

• What is actually in scope in each. The cheapest quote often excludes the admin interface, the integrations, or testing.
• Who is in the team and at what seniority. A quote assuming one junior developer and one assuming a designer, a senior developer, and a project manager are not the same product.
• What happens after launch. Some quotes include three months of support and some include none.
• Whether discovery is included or assumed to have happened already.
• Whether third-party costs — licences, services, app store fees — are inside or outside the number.

Ask each supplier to break their quote down against the same list. The exercise usually reveals that the cheap quote is not cheap, it is smaller, and that the expensive one either includes things you need or things you do not.

Working Together Once It Starts

Choosing well is half of it. The other half is how the relationship runs.

• Have one decision-maker on your side. Projects with committee approval on every question move at the speed of the slowest calendar.
• Expect working software regularly, not status reports. A demo of something running is the only credible progress signal.
• Give feedback promptly. A supplier waiting three weeks for a decision cannot maintain momentum, and the pause costs you money.
• Accept that changes cost. Changing your mind is legitimate and normal; expecting it to be free is not.
• Insist on visibility into the actual work — the repository, the issue tracker, the deployment pipeline.
• Talk about problems early. Suppliers who surface bad news late are a risk, and so are clients who punish honesty.

Plan the Ending at the Beginning

Every engagement ends, whether at launch, after years, or badly. What should exist before it does:

• Documentation covering architecture, deployment, environment configuration, and third-party services.
• All accounts and credentials in your organisation's name, not an individual developer's.
• A repository with meaningful history, not a single commit dumped at handover.
• A defined support period after launch, with agreed response expectations.
• Clarity about what maintenance costs after that, and what it covers.

Businesses that inherit an undocumented system with credentials belonging to a departed contractor pay for that omission for years. Ask for these deliverables in the contract, not at the end.

The Short Version

Decide whether you are buying capacity, delivery, or partnership, and say so. Judge suppliers on whether they push back, not on whether they agree. Treat fixed prices against vague briefs as a warning rather than a bargain. Pay for a discovery phase whose output you could take elsewhere. Own your code, your repository, and your infrastructure from day one. Cut version one harder than feels comfortable. Plan the handover before you need it.

We work with businesses across the UK, Pakistan, and the UAE, and we would rather tell a prospective client that their scope is too large or that they do not need us yet than take on a project that will not go well. If you want a straight assessment of what you are planning — including whether it is worth building at all — our contact page is the place to start.