How to choose a software development partner
Choosing who builds your software is usually a bigger decision than choosing what to build. A weak specification can be corrected in a fortnight. A poor delivery partner costs you a year, and often the codebase with it. Yet most selection processes lean on the two weakest signals available: the price on the last page of the proposal, and how impressive the portfolio looks. Neither predicts whether the thing will work in two years. Here is what we would look at instead, including the questions that are uncomfortable for a supplier to answer.
Decide what kind of engagement you actually need
Before you speak to anyone, work out which of three things you are buying, because they suit different suppliers. A fixed-scope project works when the requirements are genuinely stable and you can describe success precisely. It gives you budget certainty and gives the supplier every incentive to resist change, which is fine if nothing needs to change. A continuing product partnership works when you expect the software to evolve for years. Here you are buying a team's sustained attention, not a deliverable, and you should judge candidates on retention and continuity rather than on a single quote. Staff augmentation works when you have the architecture and the product direction in hand and simply need more capable hands. It is the cheapest per head and the most demanding of your own management time, because whatever coordination the supplier would have done becomes yours. Most disappointing engagements are one of these dressed as another. A fixed-price contract for a product that is still being discovered will produce either a change-request argument or a corner-cutting exercise, and usually both.
Judge technical depth by asking about failure
Anyone can talk fluently about the technologies on their website. What separates a capable team from a plausible one is how they discuss things going wrong. Ask for a walkthrough of a project that went badly, and what changed in their process afterwards. A team with fifteen years of delivery has several of these and will discuss them readily, because the lessons are the valuable part. A team that claims everything went smoothly is either inexperienced or not being straight with you. Ask who owns the architecture decisions and whether you will meet that person. On smaller engagements the people who impress you in the sales meeting are sometimes not the people who write the code, and you want to know that before signing rather than after. Ask how they handle testing, specifically. Not whether they test, which everyone says, but what is automated, what runs on every commit, and what a release actually involves. If the answer is vague, releases will be manual, infrequent and nervous, and that will shape your product roadmap more than any technology choice. Finally, ask what they would push back on in your brief. A partner who agrees with everything in a first meeting is selling, not consulting. The most valuable suppliers tell you which part of your plan they think is wrong.
Look past the portfolio to the delivery record
Portfolios are curated by definition. They show the projects that went well and the screens that photograph nicely. Two questions get behind them. First: how long has the client relationship lasted? A supplier with a decade-old client has been judged repeatedly by someone with the option to leave, which is a far stronger signal than a single successful launch. Ask for a reference from a client who has been with them for years, not one who launched last month. Second: is the work still running? A case study for a system that was quietly replaced eighteen months later tells you something the case study does not. It is fair to ask what happened to a project after handover. Be deliberate about sector experience. It matters most where the domain is genuinely hard or heavily regulated, such as finance, public sector procurement or anything touching personal data at scale. It matters much less than suppliers imply for ordinary business software, where general engineering quality predicts the outcome better than familiarity with your industry's vocabulary.
Get the after-launch terms in writing
The costly surprises in software procurement are almost never in the build. They are in the arrangements nobody negotiated because everyone was focused on the launch date. Settle who owns the intellectual property, in writing, before work starts. You should own the code you paid for. Where a supplier uses their own reusable components, that is often reasonable and can save you money, but you need to know which parts those are and what happens to your right to use them if the relationship ends. Settle what support actually means. Response times for a production outage, who is reachable outside office hours, and whether fixing a defect the supplier introduced is billable. These three answers vary enormously between suppliers quoting apparently similar prices. Settle how you would leave. Ask what a handover to another team looks like, and whether the documentation and deployment process would let someone else pick the system up. A partner confident in their work has no difficulty answering this. A partner whose commercial model depends on you being unable to leave will be evasive, and that evasion is the most useful thing you will learn all day.
Compare total cost, not quoted price
Two proposals for the same system can differ by half and still represent the same real cost, because the cheaper one has moved work rather than removed it. Work out, for each candidate, what you will spend over three years rather than at signature. Include the hosting the architecture implies, since a design that needs three environments and managed database instances costs more to run than one that does not. Include your own team's time, which staff augmentation consumes heavily and a managed engagement consumes less. Include the cost of the changes you know are coming, priced at the contract's change rate rather than optimistically assumed away. Then ask each candidate what they would do if the budget were twenty per cent smaller. The answers are revealing. A thoughtful partner will tell you which scope to cut and why. A weaker one will offer the same scope for less money, which means either the first price was inflated or the second one will be recovered through change requests later.
Key takeaway
The suppliers worth working with tend to make the selection process easier rather than harder. They tell you what they would not do, they are specific about testing and support, they are relaxed about how you might one day leave, and they price the work you will actually need rather than the work described in the brief. If you take one question from this into your next meeting, make it the last one: ask what they would cut if the budget shrank by a fifth. The quality of that answer tells you most of what the rest of the process is trying to find out.