How to evaluate a custom software development partner

Choosing a development partner is a high-stakes decision made with poor information. Everyone shows polished work, everyone claims senior engineers, and the proposals look broadly similar apart from the price. Meanwhile the real variance between vendors is enormous - and it shows up four months in, long after the decision is irreversible.

What follows is the set of questions we would ask if we were on the buying side. Several of them are uncomfortable to answer, which is precisely why they are useful.

Start with the signals that do not work

A portfolio of attractive screenshots is nearly worthless as a quality signal. You cannot tell from an image whether the system underneath is maintainable, whether it shipped on time, whether it still works, or whether the agency simply designed it and someone else built it badly. Visual polish is the cheapest thing to demonstrate and the least correlated with delivery.

Team size tells you nothing either. A fifty-person agency may assign you two juniors and an account manager; a six-person studio may give you its founders. Ask who specifically will work on your project, how much of their time you get, and whether that is contractual or aspirational.

Technology lists are the same. Every agency lists every framework. The relevant question is not whether they have heard of your stack but whether they can explain why they would choose it for your problem - and what they would choose instead.

Ask what went wrong

This is the single most informative question available to you: "Tell me about a project that went badly, what caused it, and what you changed afterward."

Every agency with real delivery history has projects that overran, scope that was misjudged, or a client relationship that broke down. A vendor who cannot produce one is either very new or not being straight with you. What you are listening for is specificity and ownership: a concrete failure, an honest cause that implicates their own judgment, and a specific process change.

Answers that place the cause entirely with the client - "they kept changing requirements" - are a warning. Requirements always change. A partner whose process cannot absorb that will have the same problem with you.

Interrogate the estimate, not the price

If a vendor gives you a fixed price for a substantial build from a brief alone, be careful. Nobody can accurately estimate work they have not investigated. There are only three ways that number can exist: it is padded heavily enough to absorb the unknowns, it will be renegotiated once work is underway, or the scope will be cut quietly to fit.

The healthier pattern is a paid discovery phase with its own fixed price and its own deliverable, producing an estimate grounded in actual requirements. Crucially, you should own that output and be able to take it to another vendor. If discovery is only useful as an input to that agency's proposal, it is a sales process wearing a deliverable's clothes.

Ask the ownership questions in writing

These sound procedural and they are where real disputes originate. Get each answer into the contract rather than the sales conversation.

• Who owns the source code, and from what point - on payment of each invoice, or on final payment?
• In whose name are the cloud accounts, domain registrations, and app store listings? They should be yours, with the vendor added as a collaborator.
• Who holds the production credentials, and how are they transferred at the end?
• Are there any proprietary components, internal libraries, or licensed frameworks we would need to keep paying for?
• What happens to our data and environments if we terminate early, or if you cease trading?

A partner who finds these questions reasonable and answers them crisply has thought about handover. One who deflects is telling you something about the exit before you have signed the entrance.

Probe how they handle uncertainty

Describe a genuinely ambiguous part of your problem - something you have not resolved internally - and watch what happens. Weak partners answer immediately and confidently, because confidence sells. Strong ones ask several clarifying questions, name the information they would need, and tell you which parts they cannot assess yet.

You want the second kind. Software projects fail far more often from confidently pursuing the wrong thing than from technical incapacity.

Check whether they will tell you no

Ask directly: "Under what circumstances would you tell us not to build this?" A partner with real judgment can answer concretely - when an off-the-shelf product already covers the need, when the underlying problem is organizational rather than technical, when the timing is wrong, when the budget cannot support the ambition.

The most valuable thing a technical partner can tell you is that you do not need what you came to buy.

An agency that cannot imagine declining work is an agency whose advice is structurally unreliable, because it has only one recommendation available.

Ask how you will know things are on track

Percentage-complete reporting is close to meaningless in software. What you want instead is working software at a regular cadence - something you can use at the end of every increment, in an environment you can reach.

• How often will we see a working build, and in which environment?
• Do we get access to the backlog and issue tracker?
• Who is our day-to-day contact, and are they technical?
• How will we hear about a delay - and how quickly?
• What does the weekly written update contain?

The last point matters more than it sounds. A partner who proactively reports bad news in the week it emerges is manageable. One who reports green until the deadline is not, and the difference is almost always visible in the first month.

Run a small paid trial

Where it is practical, buy something small first. A discovery engagement, a technical audit, a single well-defined feature, a design system. Two or three weeks of real collaboration tells you more about communication, rigor, and honesty than any number of reference calls.

References, incidentally, are nearly always positive - vendors nominate them. If you take them anyway, ask specifically about the hardest moment in the engagement and how the agency behaved during it.

A short checklist

1. Ask what went wrong on a previous project, and listen for ownership rather than blame.
2. Refuse fixed prices on unexamined scope; pay for discovery you own outright.
3. Get code, account, and credential ownership written into the contract.
4. Present an ambiguous problem and reward the partner who asks questions instead of answering instantly.
5. Ask when they would advise you not to build, and expect a concrete answer.
6. Require working software on a regular cadence, plus access to the backlog.
7. Buy something small before you commit to something large.

None of this guarantees a good outcome. But it reliably filters out the vendors whose only demonstrated skill is winning the pitch - and that is most of the risk you can actually control at the point of choosing.