If your agency keeps missing dates and you no longer trust the code, that is a stressful place to be. The good news is that switching app development agency mid-project usually costs weeks, not months, if you secure your accounts first and audit before you rebuild.

Most of the time lost in a bad switch comes from two mistakes. Teams fire the agency before they hold the keys. Or they assume the code is worthless and start again.

Diagnose the project yourself in under an hour

You don't need to read every file to judge a codebase. You need read access to the repository, the issue tracker and the crash dashboard. These are the checks we run first, with rough times.

1. Commit history (10 minutes)

Clone the repository and run two commands:

  • git log --since="3 months ago" --oneline | wc -l counts recent commits.
  • git shortlog -sn --since="3 months ago" shows who wrote them.

Good looks like steady commits most weekdays from two or three consistent people. Bad looks like one huge commit every few weeks, or a new author every month. Big, rare commits often mean work happens somewhere you can't see.

2. A clean build (15 minutes)

Ask a developer outside the agency to clone the repo and follow the README. A healthy project builds and runs locally in under 30 minutes on a new machine. If it needs a call with the agency or a secrets file sent by email, you don't yet own a working product.

3. Tests and CI (10 minutes)

Open the pipelines tab in GitHub, GitLab or Bitbucket. Good means every pull request runs tests and the main branch is green. Bad means no CI at all, or a red pipeline nobody has fixed in weeks.

4. Dependency age (10 minutes)

Run npm outdated and npm audit for JavaScript projects, or flutter pub outdated for Flutter. A few minor versions behind is normal. Being two or more major versions behind on React Native or Flutter means upgrade work is piling up.

5. Crashes and bug flow (15 minutes)

In Firebase Crashlytics or Sentry, find the crash-free users figure. Well-run consumer apps typically sit above 99.5%, and users notice once it drops below about 98%. Then check the tracker: if closed bugs often reopen, fixes aren't being tested.

A free code or performance audit gives you an independent read on the codebase before you commit to a switch.

The most common causes, ranked

In our rescue work, the root cause is rarely just weak developers. These are the causes we see most, from most to least frequent in our experience.

  1. No shared definition of done. Scope lives in calls and chat threads, so both sides remember different promises. The code may be fine; the process is broken.
  2. A rotating or junior team. The senior people sold the deal, then moved on. Each new developer relearns the codebase and adds their own patterns.
  3. No tests or CI. Every release breaks something old, so the team spends more time on regressions than features.
  4. Wrong architecture for the product. Examples include a backend that can't handle real concurrency, or offline sync bolted on late.
  5. Abandoned or unsupported dependencies. A core library stopped getting updates and now blocks OS or framework upgrades.

Causes one and two are management problems. A new team with a better process solves them without touching much code.

Fix or rebuild: how to tell

Rebuilding feels clean, but it resets your timeline. A rebuild of a mid-sized app typically takes 4 to 9 months, and you ship nothing new during that time. We default to fixing and recommend a rebuild only when the evidence forces it.

Usually a fix

  • The project builds, even if the steps are messy.
  • The data model matches how the business works.
  • Bugs cluster in a few screens or services.
  • The framework is one or two major versions behind.

Usually a rebuild

  • The data model is wrong at its core, and every feature works around it.
  • Security flaws run through the whole app, such as auth checks only on the client.
  • The stack is end of life with no realistic upgrade path.
  • Nobody can build it, and recovering the build costs more than rewriting.

Mixed cases are common. Then we replace one module at a time behind the same API while the app stays live. This is slower than a big rewrite on paper, but users never see a freeze.

Switching app development agency: protect yourself first

Don't give notice until you hold admin access to everything. Most agencies behave well during a handover, but you shouldn't depend on goodwill. Ask for access as routine housekeeping while the relationship still works.

Accounts to move into your name

  • Source code: repositories in a GitHub or GitLab organisation you own. GitHub documents how to transfer a repository without losing history.
  • App stores: the Apple Developer and App Store Connect accounts, plus the Google Play Console, registered to your company.
  • Cloud and billing: AWS, Google Cloud or Azure, with your company as the billing owner.
  • Domains and DNS: the registrar account and DNS host.
  • Third-party services: Firebase, Sentry, Stripe, email providers, analytics and CI.
  • Secrets: API keys, iOS certificates and Android signing keys.

The Android signing key needs special care. With Play App Signing, Google holds the app signing key, so a lost upload key can be reset. Without it, a lost key means you can't update the same listing.

Contract checks

  • IP assignment: the code is yours on payment, not on project completion.
  • A handover clause listing what the agency delivers when the contract ends.
  • A notice period you can live with, typically 2 to 4 weeks.
  • The final invoice tied to a signed handover checklist.

Documentation to request

  • An architecture overview, even a one-page diagram.
  • A list of environment variables and where each secret lives.
  • Deployment steps for staging and production.
  • Open bugs, known risks and half-finished branches.

What the first week of a rescue looks like

A rescue should produce answers fast, not a three-month discovery phase. This is how we run week one.

  1. Day 1: confirm access to every account on the list above. Rotate shared passwords and API keys the old agency held.
  2. Day 2: build from a clean machine and deploy to staging. Write down every missing step.
  3. Days 3 and 4: audit code, dependencies, security and crash data. Interview you about what users complain about most.
  4. Day 5: deliver a written report with a fix-or-rebuild call and a cost range. Ship one small, real fix to production.

That last step matters most. It proves the new team can build, test and release your app end to end. If a new agency can't do that in a week, ask why before you sign anything longer.

FAQ

How long does it take to switch app development agencies?

The handover itself typically takes 2 to 4 weeks if you hold account access before giving notice. Expect another 2 to 4 weeks before the new team moves at full speed. Projects that start without access or documentation often lose months.

Who owns the code if I switch agencies?

It depends on your contract's IP assignment clause, so read it before you act. Most agency contracts assign ownership once invoices are paid. If the clause is unclear, ask a lawyer before you withhold any payment.

Should I rebuild my app from scratch with a new agency?

Usually not. If the project builds and the data model fits the business, fixing it is faster and cheaper. Rebuild only when the core design, security or stack is broken beyond repair.