The Burned-Once Founder's Guide to Hiring a Dev Shop Without Getting Burned Twice
If you've already paid a software agency that disappeared, delivered unusable code, or shipped something your team never used, then you're in an expensive club. The question you're now asking isn't "how do I find a good dev shop," it's "how do I know this time, before I hand over real money again?"
Here's the uncomfortable truth: most vetting advice doesn't actually answer that question. It tells you what to look for in a contract, which red flags to spot in a pitch, and how many references to call, but none of that gives you certainty before you commit, because the evidence you actually need, whether they can build what you need, whether they understand your problem, and whether this thing will actually get used, has always been locked behind payment. You've been asked to pay to find out.
This guide is for the second-timer, the founder who won't pay to find out again. It covers what really goes wrong, what the standard vetting advice misses, and what you should actually demand from any shop before a penny moves.
What actually happened to you (and why it keeps happening)
The pattern is well-documented. An agency takes the deposit, communication slows in weeks two or three, and the first delivery looks like something, a few screens, some working pieces, and then the relationship quietly changes. By the time you realise the shop has effectively moved on to their next client, you've paid 50% or more and you're holding something incomplete, untested, or built on a platform you can't maintain.
One version of this is abandonment outright, where the agency goes quiet, the domain expires, and the LinkedIn profiles disappear. The other, just as common, is softer: the app ships but it doesn't work right, your team never really uses it, and when you need changes six months later there's no one home. A buyer review that surfaces repeatedly in this category puts it plainly:
It was almost as if they forgot about the app once they got the money.
This isn't bad luck, it's structural. When a shop's incentive ends at shipping, when their fee is paid in full before adoption ever happens, there's no mechanism keeping them invested in whether the thing actually works for you. They moved on, you got the code, and that's all "done" ever meant in their contract.
The trust gap runs even deeper than the abandonment pattern, though. As a non-technical founder, you can't read code, so you're buying on a portfolio curated by the agency, a pitch they've made a hundred times, and a promise. Only 4% of dev shops publish their prices, so you're negotiating blind on cost, and the all-in cost, after the integrations, the support tails, and the scope creep, routinely lands 30–50% above the initial quote. You have no independent way to judge whether the team can actually build what you need, whether they understood the problem, or whether the quote reflects reality.
The category asks you to pay to find out, and when you've found out the hard way once already, nobody refunds you for the learning.
Why the standard vetting checklist doesn't protect you
The advice you'll find on how to vet a dev shop is not wrong. Ask for references, read the contract carefully, make sure you own the IP, check their Clutch reviews, and get milestone-based payment terms instead of paying upfront. All of these things matter, but none of them are what you actually need to know.
References are curated, so you'll speak to the clients the shop has chosen to put forward, after the relationship is over and at a point where there's no incentive for them to surface a bad one. Clutch reviews are filtered through what founders are willing to say in public, after the fact. And portfolio projects are shown at their best, usually with the most technically capable work on display, rather than the project that shipped eight months late or the one a different agency had to rescue.
Milestone-based payment is the right structure, but it only protects you from losing everything, not from spending six months and sixty thousand pounds to discover the team wasn't right for you in the first place.
What you actually needed to know before committing was this: can they build what I need, in the way I need it, with people who understand my problem? The standard checklist doesn't answer that question, it just makes the contract slightly less catastrophically one-sided.
What red flags actually look like in practice
There are patterns that consistently precede the bad outcomes. Some of them overlap with the standard advice, and some of them don't.
They quote without digging. A shop that sends you a proposal within 24 hours of a first call hasn't understood your problem, they've simply slotted you into a template, which means the quote will be wrong and the scope will drift. Real understanding takes time and genuine back-and-forth, so if they're moving that fast, they're not actually learning anything.
The pitch is sharper than the questions. A good agency is more interested in your problem than in explaining their own process, so if the conversation is mostly them presenting and very little of it them interrogating what you actually need, they're selling rather than building.
Vague ownership language. IP transfer should be explicit, with all code, all designs, and all documentation yours upon payment and no licenses retained. If the contract is hedged on this, if it says something like "code produced under our platform" or "subject to retained rights," then that's both a red flag and a leverage point if things later go wrong.
Full upfront payment expectations. Fifty percent or more on signing, with the rest due at launch, is a structure that concentrates their incentive at the start and removes it at the end, so the closer the payment structure mirrors delivery, the better. Milestone-gated payments with defined acceptance criteria are the bare minimum.
No clear answer on what happens after launch. Consider the founder who called the week after launch to report bugs and got no response, because this isn't unusual at all: the agency had simply moved on. If there's no clear, contracted answer to "what support is included, for how long, and what does it cost after that," then you're not really getting an answer, you're getting a guess.
They don't push back. This one is counterintuitive. What you want is a shop that slows you down, asks hard questions about your assumptions, and tells you plainly when what you've described won't work the way you're imagining it. An agency that nods and smiles at everything you say is an agency that will build exactly what you asked for, even when what you asked for was wrong, and that's expensive agreement.
The one question all the vetting can't answer
Here's the problem none of the above actually solves.
You can do everything right, with the references, the contract, the IP terms, and the milestone payments all in place, and you'll still not know, until it's too late, whether the team actually understood what you needed and can build it. That isn't a process failure, it's structural, and the certainty you need comes only from seeing the thing work. Not a wireframe, not a clickable mockup, and not a scoping document that says "here's what we'd build," but a real, working product with real business logic, something you can operate, put in front of a real user, and judge with your own eyes.
The reason this has never really been an option in the category isn't that it can't be done, it's that doing it costs the agency something, namely a week of real work, up front, on spec. Shops don't do it because there's been no incentive to, and so the market has trained buyers to commit before seeing anything real, and to pay for that uncertainty with bad hires, wasted budgets, and shelf-ware.
So the question worth asking any shop you're considering is simply this: will you build me a working version of this, before I pay you anything? Most can't, and most won't, and that answer tells you something real about what they're offering.
What "proof before payment" actually looks like
A working, functional build, not a prototype and not a demo environment with canned data, but something with actual business logic you can operate, in seven days, before a single pound or dollar changes hands. That's the version of vetting that answers the question nobody else can answer: is this the right team, do they understand the problem, and can they build it?
If the build is wrong, you walk away for free, and you've lost nothing except the time spent explaining the project, while the agency has lost a week of real work. That asymmetry matters, because it means they won't take the engagement at all unless they're genuinely confident they can deliver.
And if the build is right, if you look at it and think yes, this is the team, they understood the brief, this is something I can work with, then you proceed with your eyes open rather than your fingers crossed, because you've already seen them work. That's the whole difference between a vetting process and a vetting outcome.
What the second problem is, and why you shouldn't ignore it
There's a second way things go wrong that burned-once founders often miss, because the first time around it's easy to attribute to the wrong shop rather than to the model itself.
Software ships and doesn't get used.
The statistics that exist on this come mostly from enterprise software and SaaS, where the numbers are stark, but the pattern is documented qualitatively in custom builds just as often: software paid for, deployed, and then bypassed. Teams build workarounds, and the tool gets used only because it's mandatory, and even then only as a place to paste things that actually happen in a spreadsheet somewhere else. When the agency's job ends at launch, adoption becomes your problem, because there's no mechanism keeping them invested in whether your team actually uses the thing they built, and the guaranteed outcome of that structure, eventually, is software sitting on a shelf.
The answer is an agency that owns the adoption outcome rather than just the delivery, and puts its own money on the line for it. A concrete version of that is 20% of the fee held until your people are genuinely using the software, across a defined window, against a measurable threshold. Not a goodwill promise, but a structured instrument with real financial skin in the game.
The distinction matters because of what happened to Naked Development, a US agency that marketed "the only money-back guarantee in the industry." When a build went wrong, the guarantee collapsed into legal disputes, because independent engineers assessed the code as unlaunchable and the refund claim became a fight the buyer had to wage. A promise without a mechanism behind it is just a pitch, whereas the mechanism itself, a defined threshold, an automatic trigger, and real money at risk, is what makes the commitment hold when it costs something.
The five things to demand before you hire anyone again
This is what vetting looks like when the lesson from the first time is actually applied:
- A working build before any money moves. Not a proposal, not a scoping document, and not a mockup, but a functional product with real logic, built to your brief, that you can judge with your own eyes. If they won't do this, you're back to paying to find out.
- Full IP and code transfer from day one. Everything built for you, the code, the designs, and the documentation, is yours throughout, with no licenses retained, no lock-in, and no situation where their vanishing means you can't keep your own software alive. Ask for this in writing before you talk about anything else.
- Line-by-line pricing, nothing hidden. Only 4% of dev shops publish prices, so ask for the full breakdown: what's in scope, what it costs, what changes the cost, and what the support tail looks like after launch and what that costs. A shop that gives you a clean answer is a shop with something to prove by being transparent, while one that hedges now is one that'll hedge later too.
- A structured adoption commitment, not a vague guarantee. Ask what happens if your team doesn't use the software. A real answer is a number, a percentage of the fee, tied to a specific threshold, a defined usage metric, with a specific timeframe, a 90-day window, and a specific trigger that's automatic rather than negotiated. Anything softer than that is just a promise, and you've already learned exactly what promises are worth.
- Milestone payments tied to working software, not to time. Payment follows delivery and acceptance rather than calendar weeks, each milestone has defined criteria, and you don't pay for the next phase until the last one is working and you've signed off.
How to tell the difference between a builder and a sales deck
The most reliable signal, in the end, isn't in the contract at all, it's in the first conversation.
A builder asks more questions than they answer. They want to understand what you're actually trying to do, the business problem underneath the software ask, before they start talking about how they'd build it. They push back on your assumptions, and they tell you plainly when something you've described won't work the way you're imagining it, and they speak to you like a businessperson rather than like someone who needs the technical process explained to them.
A sales deck, by contrast, talks about process, portfolio, and team size. It performs competence rather than demonstrating it, and it tells you what you want to hear.
So the test is simple: have you seen them build something yet? If you've been burned once already, the only answer worth accepting is yes.