What to Do When Your Agency Delivers Garbage Code
You paid the invoice. You got the files. And now a developer friend is scrolling through the repo with the kind of face you never want to see.
"This is... not great."
This is one of the most common situations non-technical founders end up in. You hired an agency because you needed someone technical and you weren't. They showed up with a portfolio, a proposal, and a timeline. You paid in milestones. And now you have a product that technically works, but nobody will tell you whether the foundation is solid or if you're standing on wet cardboard.
Here's how to handle it.
First: Breathe. This Is Recoverable.
Bad agency code is not a death sentence. I've seen truly awful codebases get untangled and turned into solid products. The question isn't whether it can be fixed. It's whether fixing it is worth it, or whether starting fresh makes more sense.
That answer is almost never obvious upfront. You have to look first.
What you don't want to do is panic-hire the first developer you find to "just fix it." That's how you add a second layer of technical debt on top of the first. And it's how you end up spending another $30K before you have a clear picture of what you actually have.
Step One: Get an Independent Code Audit
Before you do anything else, you need an honest assessment from someone who has zero financial interest in the outcome.
Not the agency that built it. Not a developer friend who might undersell the issues to be polite. Not a new agency who will inevitably quote you a full rebuild.
You need someone whose only job is to tell you the truth.
A code audit for a typical early-stage SaaS should cover:
Architecture review. Is the structure logical? Does it follow patterns that other developers will actually understand? Or did the agency invent something custom and weird that will confuse everyone who comes after them?
Security issues. Are there obvious vulnerabilities? SQL injection, exposed API keys, missing auth on critical routes, plain-text passwords in logs. These are not hypotheticals. I find them regularly in agency-delivered work.
Dependency state. Are they using libraries that are current, maintained, and licensed appropriately? A codebase built on abandoned dependencies is a slow-motion problem.
Test coverage. Is there any? Even a little? Code without tests is code you can't change with confidence.
Documentation. Can a new developer get the app running locally in under an hour without calling the agency? If not, you have a bus factor problem.
Deployment setup. Do you actually own and control the infrastructure? Or is it sitting in the agency's AWS account?
That last one. Make sure you own your own infrastructure before the engagement fully closes.
Step Two: Categorize What You Found
After the audit, you'll have a list of issues. Not all of them are equal. Here's how to sort them.
P0: Fix immediately. These are security vulnerabilities, data exposure risks, or anything that could affect your users right now. No timeline negotiation. Fix these first.
P1: Fix before scaling. The stuff that will cause real problems when you hit 100, 500, 1000 users. Performance bottlenecks, architectural decisions that don't scale, missing error handling that will cause silent failures under load.
P2: Fix when you touch that area. Code quality issues, inconsistent patterns, missing tests in modules you're not actively changing. These matter but they're not on fire.
P3: Accept and document. Technical shortcuts that are awkward but functional. Bad naming conventions, duplicated logic, over-engineered solutions to simple problems. You don't have to fix everything. Sometimes you just write a note that says "this is weird, here's why it's still here" and move on.
Most codebases have plenty of P2 and P3. The red flags are P0 and P1 issues that the agency didn't mention, because that tells you something about how they were operating.
Step Three: Decide on Your Path
Once you have the audit results, you have three real options.
Option A: Patch and proceed. The core architecture is solid enough. The agency cut corners in places but the foundation is defensible. You hire a developer, fix the P0/P1 issues, and build on top of what exists. This is the right call more often than founders expect.
Option B: Partial rebuild. The front end is fine but the back end is a mess (or vice versa). You keep what works, replace what doesn't. More expensive than patching, less expensive than a full rebuild. Right for situations where one part of the system is genuinely well-done.
Option C: Full rebuild. The architecture is fundamentally wrong, security issues are everywhere, and no competent developer will want to work in it long-term. This is a harder call to make and an expensive one. But sometimes it's the right answer. Better to know now than after you've added another year of features on top of a broken foundation.
Most of the time it's Option A. The agency did something weird in three places, didn't document anything, and the code style is all over the map. But the core logic works, the database schema is reasonable, and a competent developer can get up to speed in a week. That's fixable.
Step Four: Understand Your Leverage
If the agency significantly underdelivered relative to what was scoped, you have options before you pay the final invoice.
Document everything first. Save the contract, the scope of work, all Slack messages, all email threads. Screenshot the GitHub commit history if you have access to it. This is not about threatening litigation. It's about having a clear record of what was promised and what was delivered.
Then have a direct conversation. Most agencies would rather negotiate a discount or additional remediation work than deal with a dispute. Go in with specifics from the audit. "The security audit found X, Y, Z. The deployment isn't on our infrastructure. The documentation that was in scope isn't there." That's a conversation, not an accusation.
If they're not responsive or the relationship has fully broken down, check your contract for dispute resolution terms. Small claims court handles contracts under a certain amount (varies by state). Chargebacks are possible for credit card payments depending on timing. These are last resorts but they're real options.
What usually happens: the agency is embarrassed, they know the audit is accurate, and they'd rather resolve it quietly than have a bad review or a formal dispute. You have more leverage than you think.
Step Five: Transition the Codebase
Whether you patch, partially rebuild, or start over, you need to actually transition ownership of the codebase away from the agency.
Checklist:
- You have access to every repository, and the agency doesn't have admin rights they could use to lock you out
- All API keys and environment variables are rotated (assume the agency still has copies)
- DNS, hosting, and domain registrar accounts are in your name and under your email
- You have the database backups and export rights
- Any third-party service credentials (Stripe, Twilio, SendGrid, etc.) are under accounts you own
- The agency has been formally off-boarded and access revoked
This last part sounds paranoid. It isn't. I've seen situations where a founder and agency had a bad split, and the agency had lingering access to production infrastructure. That's a real risk that needs to be eliminated cleanly.
How to Avoid This Next Time
A few things that would have helped before you signed:
Talk to their last three clients. Not the references they provide. Ask for a full client list and pick people from the middle of it. The references they give you are cherry-picked. The people they don't mention are more informative.
Require a GitHub milestone structure. Each milestone should end with a code commit you can actually review, not just a demo. Paying for a working demo and paying for deployable code are different things.
Define code quality criteria in the contract. Test coverage requirements. Security scanning. Documentation standards. If it's not in the contract, it's optional.
Get infrastructure access from day one. Your AWS account, your GitHub org, your domain. The agency gets invited as a collaborator. They never own the accounts.
Build in a 30-day post-launch audit right in the contract. If the audit finds critical issues that were in scope, the agency remediates at no charge.
None of this is unusual to ask for. Agencies that push back on these terms are telling you something important about how they operate.
If you're sitting with an agency-delivered codebase right now and you're not sure whether it's salvageable, that's exactly the kind of situation where a short technical conversation pays for itself.
Book a call and we'll look at it together. No pitch. Just an honest read on what you have and what your real options are.