Agency not delivering? How to take over, rebuild and relaunch your app

If your agency isn’t delivering, don’t fire them first. Secure your code, accounts, domains and data. Then get an independent audit of what’s actually been built. Only then decide whether to fix it, replace it piece by piece or rebuild.

That last decision has changed. With experienced engineers driving AI tools, a rebuild is far faster and cheaper than it was. That moves the hard part. Writing the new code is no longer the slow bit. Getting your users, data and app store listing across to it is.

Once you’re defending your tech to the people who fund you, you’ve waited too long.

“If you have to make excuses for your tech on their behalf, to your board, your stakeholders, it’s already too late.”

How do you know your agency isn’t delivering?

A stalled project is a pattern, not a bad week. These are the signs we take seriously.

• Sprint reviews with nothing to show. A sprint is a short block of work, usually two weeks. If there’s nothing new to see or test, ask what shipped.
• Releases are rare events. Deploying means putting new code live. A team that deploys once a month often finds deploying risky.
• You can’t get into the code. If the repository, the online folder that holds your source code, lives in their account, ask why.
• Every question comes back to scope and budget. You ask for a change and get a quote.
• Fixing one thing breaks another. That’s tech debt: the extra cost of change caused by earlier shortcuts.

One sign on its own is a conversation. Three or more is a plan.

Is it them, or is it the brief?

Projects also stall because the founder keeps changing direction, or takes weeks to answer questions. If scope has moved five times, a new team inherits that.

What should you secure before you switch development agency?

For anything held in the agency’s name, ask for a transfer before you give notice. Don’t depend on goodwill at the moment it’s thinnest.

Then check the contract. In UK law, the author of a work is usually its first owner. If the author is an employee, their employer is (Copyright, Designs and Patents Act 1988, s11). So by default, the agency or its freelancers own the code. Legal ownership passes to you only by a written, signed assignment (s90(3)).

Look for an IP assignment clause, and check whether it only applies once you’ve paid in full. We cover this properly in who owns your code. This is general information, not legal advice.

As soon as the handover lands, remove the old team’s access. Rotate every password and API key they could see, with whoever runs production, so nothing breaks.

How should you end things with the old agency?

Calmly, and in writing. Ask for a handover rather than announcing a dispute. It should cover:

• transfer of every account above into your ownership
• a final push of all the code, including unfinished branches
• a short written note on how to run and deploy the project
• a list of known bugs and half-built features

Pay what you owe. A fair settlement buys co-operation, which is worth more than the last invoice.

Should you keep going because of what you’ve already spent?

No. That money is gone whichever way you choose. The only question is what the next pound buys.

This trap is the sunk cost fallacy. The fear behind it is usually the investor conversation, because nobody wants to announce they’re starting again.

What should a takeover audit cover?

A takeover audit is an independent review of what you’ve actually got. It answers one question. Can this codebase carry your product forward, and at what cost?

Good practice covers eight things:

1. Can it be run? Someone new should build and run it from scratch, using only the repository.
2. What does it actually do? Click through every screen and compare it with what you were promised.
3. What rules are buried in it? Pricing logic, permissions and edge cases often exist nowhere but the code. List them before anyone changes it.
4. How is it built? Five coding styles usually means five developers who never talked.
5. Is it tested? Automated tests are code that checks other code. Without them, every change is a gamble.
6. Is it secure? Look for exposed keys, outdated libraries and how personal data is stored.
7. What does the data look like? Every option ends with moving or reshaping it.
8. How does the team work? Look at how often code goes live, and what happens when it breaks.

Ask for a written report in plain English, with a clear recommendation. You should be able to forward it to an investor.

How has AI changed the rebuild decision?

Refactoring means improving existing code without changing what it does. Rebuilding means starting again, keeping the designs and everything you’ve learned. For years, the advice was to avoid rebuilds.

“Every single rebuild is always massively underestimated. Doesn’t matter who you speak to. Doesn’t matter who does it.”

That was true when every line was typed by hand. Experienced engineers using AI tools can write, test and document a new codebase far faster than before. A tangled codebase can now often be replaced faster than it can be untangled.

The word that matters is experienced. AI speeds up people who already know what good looks like. That’s how we use it: senior engineers review and own everything that ships.

Where careless AI refactoring goes wrong

Asking an AI tool to “clean up” a messy codebase is fast. It’s also how projects get worse.

• Lost business rules. Old code is full of decisions nobody wrote down, like a discount for one customer or an odd rounding rule. A rewrite that doesn’t know they exist quietly drops them.
• Regressions. A regression is something that used to work and now doesn’t. Without tests that pin down current behaviour, nobody notices until a customer does.
• Unreviewed code. Veracode tested more than 100 AI models on 80 coding tasks. The generated code introduced security flaws in 45% of cases.
• Data loss. In July 2025, a Replit AI agent deleted a founder’s production database during a code freeze. Replit’s CEO called it “unacceptable and should never be possible”.

None of this means avoiding AI. It means writing down the business rules first and testing the old behaviour. Review every change, and keep AI tools away from live data.

Should you rebuild, refactor or replace it piece by piece?

There’s a third option besides refactoring and rebuilding. You replace the system one piece at a time while it keeps running. Engineers call that last one the strangler pattern, after a fig that slowly grows around a tree.

A rebuild still doesn’t fix whatever caused the mess. As we tell founders, “Quite often the issue isn’t the code. Quite often the issue is the fact that their culture is [broken].”

If most of your answers sit in one column, that’s your answer. With AI-assisted engineering, a split result now leans towards rebuild more often than it used to. The exception is a busy live app with tangled data. There, replacing it piece by piece can still be safer.

What a rebuild looked like for Pristine Condition

Pristine Condition’s app checks that warehouse staff lift safely. Before the rebuild, its software had under ten percent adoption. We rebuilt it to work offline. Its AI lifting check now runs in real time on an ordinary phone camera.

Usage has since grown by around 9,000%. Around 150,000 warehouse staff now use it. With adoption that low, the product itself had to change, not just the code.

How do you plan the migration and launch?

A fast rebuild can still fail at the finish line. The other half of the job is moving real users, data and an app store listing across without losing them. Plan it from week one.

Data migration

Your users’ data is the one thing you can’t rebuild. Map every table in the old system to its home in the new one. Write the migration as a script you can rerun, not a manual export. Rehearse it on a copy of production data until the numbers match.

Parallel running or a clean cutover

There are two ways to switch. Parallel running keeps both systems live and moves users across in stages. A cutover switches everyone at once, usually in a planned quiet window.

Parallel running sounds safer, but every day of overlap lets data drift and splits the team’s attention. Keep it short, with a fixed end date.

Keep your app store listing

If you have a mobile app, don’t launch the rebuild as a new app. Ship it as an update to the existing listing, so you keep your downloads, ratings and reviews.

On Google Play, an update must use the same package name and signing key as the current version. So secure the signing key in the handover, not just the code. On the App Store, you release the rebuild as a new version of the same app. Apple lets you choose whether to reset the overview rating, and written reviews stay either way.

If the listing sits in the agency’s developer account, transfer it first. Apple says a transferred app keeps its reviews and ratings, and users keep getting updates. Apps with Sign in with Apple or subscriptions need extra preparation, so start early.

Tell your users

Users forgive change they were warned about. Tell them what’s changing, when, and what they need to do. Brief support before launch day.

Plan the rollback

Decide before launch what would trigger a switch back, and who decides. Keep the old system and a full backup ready until the new one has proved itself. Rehearse it once, so it’s a procedure rather than a panic.

Why should the migration window be short?

“The faster that can happen, the more successful the migration.”

A long migration is where rebuilds lose momentum. Every week of overlap means two systems to patch and two sets of data to reconcile. Users get caught in between, and features get built twice or not at all.

A short window forces the hard work up front: rehearsal, rollback plan, user messages. Then you move decisively, watch closely and fix fast.

When the build no longer takes a year, the old system needn’t limp on for one. A switch measured in days or weeks beats months of limbo.

What does it cost to take over a stalled project?

It depends on what the audit finds. Anyone quoting before seeing the code is guessing. Here’s what a fresh start costs with us.

Our LaunchPad is fixed price, excluding VAT: £25k for 2 months, £60k for 3 months or £100k for 4 months. Discovery sets the scope within the tier you pick. You get your money back if the plan isn’t right after Discovery. The price covers everything up to launch, including developer accounts, hosting, licences and the third-party services the build needs. You own the code and IP. The full detail is on our pricing page.

LaunchPad is about launching a successful product, not building an MVP. After launch, TotalCare runs the product for a fixed monthly price, covering hosting, app store accounts, third-party services and support.

If the audit says refactor, the work may be much smaller than a LaunchPad. The first chat is free, and so is an architectural review.

When you shouldn’t hire an agency like us

Switching isn’t always the fix. Don’t hire us, or anyone, if:

• The problem is the brief. If you can’t yet say what version one does, a new team will stall in the same place.
• You’re weeks from launch and it mostly works. Finishing with the current team, on tighter terms, may be cheaper.
• You need one fix, not a team. A single bug is often a job for a good freelancer. Our guide to agencies, freelancers and fractional CTOs helps you choose.

What’s the right order of play?

Take the order, if nothing else:

1. Note the warning signs, and check your own side of the brief.
2. Secure every account, repository, signing key and backup in your company’s name.
3. Ask for a written handover, and pay what’s fairly owed.
4. Remove the old team’s access and rotate every key.
5. Get an independent audit, and ignore what you’ve already spent.
6. Choose refactor, replace or rebuild from the audit.
7. Plan the data migration, app store release, user messages and rollback before you build.
8. Keep the switchover window short, and move decisively.

If you’re partway through this and want a second opinion, talk to us. We’ll tell you what we’d do, even if it’s to stay put.