A field guide to choosing a software partner

We get hired most often after a bad first build. The patterns are predictable. Most of them would have been visible at the proposal stage if the right questions had been asked.

This is the cheat sheet we wish more clients had before their first procurement conversation. Use it whether you're talking to us, to a freelancer, or to a big-name agency , the questions cut the same way regardless of who's answering.

Before you ask for a quote

Have they shipped something similar? Not "in the same industry". Similar in shape: same user count, same data complexity, same integration depth. Ask to see it. Click around it. If they can't show you a live system , polite alarm bells.

Who specifically will work on it? Names. Not "a senior team". Not "a dedicated squad". Names. And whether those same people will still be on it in month four. Bait-and-switch , senior names in the pitch, junior delivery in the build , is the single most common complaint we hear from clients who've been burnt.

Have you spoken to two of their past clients? Without the agency in the room. Ask: what would you do differently? What surprised you? Would you hire them again? The last question, asked plainly, is worth the whole call.

In the proposal

Is there a discovery phase? If they quote a full build off a one-hour call, that's not a partner. That's a vendor. Any honest fixed-price quote on serious work is preceded by a paid discovery , usually 1–3 weeks , because nobody can responsibly estimate a six-month build off a conversation.

Are estimates in ranges? Honest estimates have ranges. "£40k–£55k" is more credible than "£47,300". The precision of the second number is theatre. Ranges show the partner has thought about what could go wrong.

What's explicitly NOT included? Good proposals list what's out of scope, not just in. If the "out of scope" section is empty or one line long, you're going to discover the boundaries the hard way , usually in month three, via a change order.

Who owns the code? You should. Get it in writing. Also: who hosts it? Who has the production credentials? Can you walk away in month six and run it yourself or with a different team? If the honest answer is no, you're not buying software , you're renting it from this specific partner forever.

During the build

How often will you see working software? Weekly is healthy. Fortnightly is acceptable. Monthly is a warning sign. Quarterly is malpractice. You should be able to click on real, deployed software every sprint , not just see Figma frames or status reports.

Who can you call when something is broken? A name, a channel, a response-time expectation. "Email our support address" is not an answer for a system the business depends on.

How do they handle being wrong? Watch what happens the first time something is late or off-spec. The partners worth keeping say so early, explain why, and propose a fix. The ones to leave find reasons it's actually your fault.

The red flags

• They pitch the same case study to every prospect

• The discovery phase is "free" (you're paying for it somewhere, usually in inflated build costs)

• They can't show you a live system they built more than two years ago

• The team in the pitch isn't the team in the build

• They never push back on your brief

• Their proposal is mostly logos and process diagrams, not specifics about your problem

• They quote in days, not outcomes

The green flags

• They ask uncomfortable questions early

• They say no to features you suggest

• They estimate in weeks, not days or months

• They've fired clients before

• They show you something that didn't work, and what they learned

• They're willing to start with a smaller engagement to prove the fit

• Their references answer the phone quickly , a sign the relationship is current and warm

The single best signal

Ask: "What's the riskiest part of this build?" A good partner answers in 30 seconds. A bad one tells you everything will be fine.

The follow-up: "What would have to be true for this to come in late?" If they can't answer that one either, they haven't actually thought about your project , they've thought about their proposal template. Walk away.

One last piece of advice

Trust your gut on the small things. The way a partner handles a rescheduled call, a typo in a proposal, a question they don't immediately know the answer to , that's how they'll handle the build. Software projects fail on communication far more often than on code. Pick the team you actually want to talk to on a bad day.