You hired a development agency. They sent slick decks, quoted six figures, promised an MVP in three months. Twelve months and $80,000 later, you have a half-finished app that crashes on Safari, a Slack channel that has gone quiet, and a sinking feeling that the only people who understood the code have moved on to their next contract.
This post is for you. I have seen this story enough times to know it’s not bad luck — it’s a pattern. Here is what to do now, and how to make sure it never happens again.
First: Stop. Do Not Pay More.
The instinct is to throw more money at the problem. “Just one more sprint and they’ll get it working.” Resist this. Every additional dollar paid to a team that has already failed you is a dollar you cannot spend on the team that will replace them.
If you have an active contract with a per-sprint or retainer structure, pause it. You are allowed to do this. The agency’s commercial interest is in keeping you on the meter; your interest is in honesty.
Second: Get a Technical Audit From Someone You Don’t Pay To Continue Building
This is the most important step and it’s the one founders skip.
The agency that built your software cannot give you an honest assessment of it. Their incentives are wrong. Their bias is in the foundation they laid. You need a senior engineer who has zero financial interest in either continuing the existing project or selling you a rebuild.
A real technical audit answers four questions:
- What is actually working? Sometimes more than you think. Don’t trash everything.
- What is broken in a way that can be patched? Not all bad code needs to be thrown away.
- What is broken in a way that cannot be patched? Foundational decisions — wrong database, wrong auth, no tests — sometimes mean rebuild is cheaper than rescue.
- What is the realistic cost of moving forward? Both options: patch and rebuild. With ranges, not single numbers.
I do these audits as a free 30-minute technical review for founders in this exact situation. Other senior engineers do too. The audit is your fastest, cheapest path back to clarity.
Third: Understand How You Got Here
Most dev-shop disasters share a small set of root causes. Recognizing them in your own story is the first defense against repeating them.
You bought on the deck, not the team. The salesperson who sold you the engagement is not the engineer who built your software. The team you saw in the proposal is rarely the team that did the work. The good engineers got moved to other accounts when something more lucrative came in.
You did not have a technical advocate on your side. Every engagement has a buyer and a seller. If you are a non-technical founder, you were buying something you could not evaluate. Of course you got the version they wanted to sell you.
There were no demos of working software. Real progress looks like working software you can click on, every week. If your status updates were Gantt charts and percentages and “next sprint we’ll have…,” nobody was shipping.
The agency owned the deployment. If your app is hosted on the agency’s infrastructure, on their accounts, under their domains, with their credentials — you do not own your software. Get the keys back before you do anything else.
You did not own the source code. Some agencies will technically deliver source code that is unbuildable on any machine but their own. Custom build scripts, undocumented dependencies, secrets embedded in environment variables only they have. Verify your codebase builds on a clean machine before you accept any handoff.
Fourth: Decide — Rescue, Rebuild, or Walk Away?
After the audit, you will be in one of three positions.
Rescue is viable when the architecture is fundamentally sound and the problems are tactical: bugs, missing features, performance. Rescue means a new engineer or team takes over the existing codebase, patches what’s broken, and ships from where you are. Costs less than a rebuild. Faster to revenue.
Rebuild is necessary when the foundation is wrong — wrong database for the problem, security architecture that won’t pass a real audit, framework choices that prevent the features you actually need. Rebuild from scratch. Often cheaper than rescue, despite the optics, because you stop fighting decisions that were never going to scale.
Walking away is the option nobody talks about. Sometimes the business case for the original idea has shifted, or the runway will not survive another full build. If your audit reveals that finishing the product still leaves you with a $200k engineering bill against a market that may not exist, the right move may be to learn the lesson and start over with a different idea.
There’s no shame in any of these. There’s shame in continuing to pay a dev shop that has already proven it cannot deliver.
Fifth: Hire Differently Next Time
If you decide to rebuild or rescue, here is how to avoid the same trap.
Engage a fractional CTO before you engage developers. Hire a senior engineer for 5-10 hours per week before you hire the team that builds. The fractional CTO writes the architecture, evaluates vendors and contractors, reviews code weekly, and represents your technical interests. The cost is a small fraction of the engagement, and the leverage is enormous. This is exactly the gap that fractional CTOs exist to fill — and the people doing this work have seen the failure pattern enough times to design around it. Read more about fractional CTO engagements.
Pay for outcomes, not hours. Fixed-price deliverables tied to working software, demoed every Friday. Not “milestones” that are abstractions of progress. The deliverable is the working app, not the document describing the work.
Insist on weekly demos of working software. No exceptions. If your team cannot show you something working every week, they are not shipping. Working software is the only honest unit of progress.
Own everything from day one. Source code in your GitHub. Cloud accounts in your name. Domain in your registrar. Every credential, every secret, every key. The team has access; you have ownership.
Hire senior engineers, not “teams.” A team of three juniors costs the same as one senior and ships half as much. The asymmetry is brutal at the early stage. Founders who got burned by an agency almost always got burned by junior engineers being billed at senior rates.
What This Looks Like When It Works
The contrast between a stalled dev-shop engagement and a working engineering relationship is stark. In a working relationship:
- You see working software every week.
- Code is in your repository, deployable by you.
- Architecture decisions are explained, not asserted.
- Bad news arrives early, not in month nine.
- The engineer pushes back on your ideas when they are wrong, and you trust their judgment because they have earned it.
If your current relationship has none of these signals, that is the data you needed. Act on it.
Where to Go From Here
If you’re in this situation right now, book a free 30-minute technical triage. I will look at what you have, tell you what’s salvageable, and give you a clear path forward — whether that’s working with us, working with someone else, or walking away. No sales pitch. The diagnosis is the deliverable.
You have already paid the tuition. The least you can do is take the lesson.