--- title: "How to Switch Dev Agencies Mid-Project Without Losing Your App" author: "Nate Laquis" author_role: "Founder & CEO" date: "2026-10-10" category: "How to Build" tags: - switch dev agency mid-project - change development agency - software project handoff - code audit - agency contract termination excerpt: "Changing agencies halfway through a build is survivable if you do it in the right order. Secure your accounts first, audit the code second, and only then decide what to keep." reading_time: "13 min read" canonical_url: "https://kanopylabs.com/blog/how-to-switch-dev-agencies-mid-project" --- # How to Switch Dev Agencies Mid-Project Without Losing Your App ## Signs It Is Time to Leave Most founders wait too long. They sit through three missed milestones, a rotating cast of developers and a demo that looks the same as last month's, because switching feels like admitting the money is gone. It is not gone. What you already paid for is the code, the designs and what you learned about your own product. The only money you can still save is the money you have not spent yet. These are the signs that matter, in rough order of how serious they are: - **Demos stopped happening.** You get status updates in writing but never see the working product. A team that is making progress wants to show it. - **The same bug keeps coming back.** Fixes that do not hold usually mean there are no tests and nobody understands the code well enough to change it safely. - **Estimates keep moving, always upward, always with a reason.** One slip is normal. Four in a row is a pattern. - **The people changed and nobody told you.** The senior engineer from the sales calls is gone and you are now talking to someone who joined last month. - **They get defensive when you ask for access.** This is the one that ends the conversation. Your repo and your cloud accounts are yours. A good agency hands them over on day one without being asked. - **Budget burned at a rate that does not match what you can see.** If you are 70 percent through the money and the product feels 30 percent done, believe your eyes. One bad week is not a reason to leave. A bad quarter is. Before you decide, spend an afternoon on the basics in our guide to [evaluating developer work](/blog/how-to-evaluate-developer-work). If you can still run the app, click through it and read a commit history that shows steady activity, you may have a communication problem you can fix. If you cannot do any of those things, you have a different problem, and the rest of this article is for you. ![Founder reviewing project progress charts and dashboards on a laptop during an agency review](https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800&q=80) ## Secure Access Before You Say a Word Do this before the difficult conversation, not after. Agencies are mostly professional, and most handoffs go fine. But the one that does not go fine costs you months, and the fix takes an afternoon. Get your hands on everything you own while the relationship is still calm. Start with an inventory. Write down every system the project touches and, next to each, who owns the account today. You will be surprised how often the answer is the agency. - **Source code.** The repository should live in a GitHub, GitLab or Bitbucket organization that you own, with you as an owner. If it sits in the agency's organization, create your own and mirror the full repository, including all branches and tags, not just the main branch. Then confirm the history came across. - **Cloud hosting.** AWS, Google Cloud, Azure, Vercel, Render, Fly.io, Heroku or whatever you run on. The account should be under your billing and your root login. Agencies sometimes host client apps in their own AWS account for convenience. That is a migration project, not a login change, so find out now. - **Domain and DNS.** Check who the registrant is at your registrar and who controls the DNS records. Losing a domain is a very bad week. - **Apple and Google developer accounts.** The Apple Developer Program account and the Google Play Console must be registered to your company, not the agency's. Apps cannot be moved freely between accounts, and a transfer requires the app to meet specific conditions, so confirm yours now. If the agency published under its own account, ask Apple and Google what a transfer needs before you tell anyone anything. - **Third-party services.** Stripe, Firebase, Supabase, Twilio, SendGrid, Sentry, analytics, your error tracker, your CI service, your push notification provider. List each one and check whose email is on the account. ### Rotate credentials, but in the right order Every person who worked on the project has seen some of your secrets: API keys, database passwords, signing certificates, environment files. You are not accusing anyone by rotating them. It is the same hygiene you would apply when any employee leaves. The order matters. First, add yourself or your new team as owners everywhere. Second, remove agency staff from accounts they no longer need. Third, rotate secrets one service at a time, deploying the new value and confirming the app still works before you move to the next. Rotating everything at once is how you take production down on a Tuesday. Mobile signing keys deserve special care, because losing an Android upload key or an iOS distribution certificate can block your next release. Make sure you hold copies. Also turn on two-factor authentication on every account and make sure it is tied to a phone or authenticator you control, not a shared inbox the agency can read. ## Pay the Incoming Team for a Code Audit Do not let a new agency quote the rest of the project from a demo and a slide deck. They are guessing, and the guess will either be a lowball designed to win you or a padded number designed to protect them. Pay for a proper audit instead. It typically runs one to two weeks, and market rates for it vary a lot depending on the size of the codebase and who does it. Expect somewhere in the low-to-mid four figures for a small app and more for a large one. That money is the best spent in the whole process. You get a written, independent view of what you actually own. ### What a decent audit covers - **Does it build and run from scratch?** A new engineer should be able to clone the repo, follow the README and have a working local copy. If that takes a week of hand-holding, the project has a documentation problem at minimum. - **Architecture.** Is the structure sensible for the product you are building, or is it a pile of copy-pasted screens? - **Test coverage and CI.** Are there automated tests? Do they pass? Is there a pipeline that runs them? - **Security.** Hard-coded secrets, outdated dependencies with known vulnerabilities, missing input validation, open storage buckets, weak authentication. - **Data model and migrations.** Databases are the hardest part to fix later. A bad schema outlives every other mistake. - **Delivery state.** What is finished, what is half-built and what is only a mockup. Compare it to the list of features you were told were done. The deliverable should be a written report with severity ratings and a rough estimate to fix or finish each item, not a verbal opinion. Ask the auditor to separate problems that are annoying from problems that block growth or put user data at risk. One rule: the audit should be a separate, fixed-scope engagement with its own price. If a team offers it free and folds the cost into a big proposal, they have a reason to find that the old code is garbage. A paid audit lets them tell you the truth even when the truth is that the code is fine and they will make less money. Get a second opinion if the first auditor is also the one bidding to rebuild everything. For help reading bids, see our list of [software development proposal red flags](/blog/software-development-proposal-red-flags). ## Continue or Rebuild: Make the Call With the Audit in Hand Every new agency has an incentive to say rebuild. A fresh start is easier to estimate, easier to own and easier to bill. Be suspicious of any team that decides on the rebuild before reading your code. Equally, be suspicious of anyone who says everything is fine and just needs a few tweaks, because that is also the answer that wins the contract. Here is how I would weigh it. Continue when the code builds, the structure is understandable, the data model is sound and the problems are local, meaning a bad module, a missing test suite or a few security fixes. You keep the working product and replace the parts that are weak. This is almost always faster and cheaper than starting over. Rebuild when at least two of these are true: - The foundation is wrong for the product, such as a no-code or template base that cannot support your core feature. - The data model needs restructuring and live data would have to be migrated by hand. - Security problems are spread through the whole codebase rather than sitting in a few files. - No engineer on the incoming team can explain how a core feature works after a week of reading it. - Fixing the existing code will cost more than 60 to 70 percent of a rebuild. That is my rough rule, not a law, but past that point you are paying a premium to keep code you will not like working in. There is also a middle path that gets overlooked: strangle the old code gradually. Keep the live product running, and rebuild one module at a time behind it, starting with the part that hurts most. It takes longer on the calendar but removes the cliff-edge risk of a big-bang cutover. If AI tools or no-code platforms produced the original build, our [decision framework for rebuilding a vibe-coded app](/blog/when-to-rebuild-vibe-coded-app-decision-framework) goes through the same question in more depth. Whatever you choose, get the scope, the timeline and the cost written down. A fixed range with clear assumptions beats an open-ended hourly arrangement while the team is still learning your code. ![Developer reading source code on a monitor while auditing an existing application](https://images.unsplash.com/photo-1555949963-ff9fe0c870eb?w=800&q=80) ## Exit Terms, Ownership and the Final Invoice Now read your contract. Do it before you send any notice, and ideally with a lawyer who handles technology agreements. Nothing here is legal advice. Terms vary by agency and by jurisdiction, and a lawyer's review of a few pages costs far less than a dispute. Look for these clauses: - **Termination.** How much notice is required, and whether you can end for convenience or only for cause. Some contracts require 30 days. Some tie you to a minimum term. - **Intellectual property.** Who owns the code. Many agreements say ownership transfers to you only on final payment. Check whether it covers work in progress. If the contract is silent, that is a problem to raise with a lawyer, not to assume away. - **Work in progress.** What you receive for the current sprint if you leave in the middle of it. - **Third-party and open-source components.** Whether the agency reuses its own internal frameworks, and whether you get a license to them. - **Transition assistance.** Whether the agency must help with knowledge transfer after notice, and at what rate. - **Non-solicitation.** Some contracts bar you from hiring the agency's developers for a set period. If you were planning to hire the one good engineer, check first. ### The final invoice Do not withhold payment for work that was delivered and accepted. Withholding turns a handoff into a dispute. Pay for what you received. If you believe specific work was not delivered or was defective, state that in writing, with evidence from the audit, and ask for a credit or a corrected invoice. Pay the undisputed portion on time. Ask for a closing package in the termination letter: the full repository with history, a list of every account and credential, environment files, deployment instructions, database backups and design files, with a date by which each is due. Keep the tone businesslike. You may need these people to answer questions for a month, and a cooperative exit is worth more than a satisfying one. Aim to hold the last invoice until the closing package is delivered and verified. Agree to that in the notice, not afterwards, so it reads as a clear condition of a clean finish and not a punishment. ## Knowledge Transfer That Actually Transfers Knowledge Code explains what the system does. It rarely explains why. The reasons live in the heads of the people who built it, and you have a short window to get them out. Plan two to four weeks of overlap if the contract allows it, and book the sessions before the old team has mentally checked out. Ask for these specific things: - **Recorded architecture walkthroughs.** One person, screen share, 60 to 90 minutes, talking through the main components and how data flows. Record it. A transcript is a bonus. - **A deployment dry run.** The incoming engineers deploy to production, or at least to staging, with the outgoing team watching. Anything undocumented shows up fast. - **Known issues list.** Every bug, shortcut and "we will fix that later" the team can remember. Ask for it directly. People are more honest on the way out than they were on the way in. - **Third-party quirks.** The payment webhook that needs a retry, the App Store review note that got you approved last time, the cron job that nobody has touched since launch. - **Environment setup.** A fresh engineer on a clean machine follows the README without help. Fix whatever breaks. - **Access to the people.** A named contact for questions during the first month, with an agreed response time and a rate if it is billable. Treat the README as a test. If the new team cannot get the project running from it, the handoff is not done. Have them update it as they go, so the document improves with every question they ask. ## The First 30 Days With the New Team The first month should not be about shipping new features. It is about getting the project safe, understood and moving again. A sensible plan looks like this. ### Week 1: stabilize Confirm every account and credential is transferred and rotated. Get monitoring and error tracking in place, if there is none. Set up backups and confirm you can restore one. Run the audit's critical security fixes first. Production should be no more fragile at the end of the week than at the start. ### Week 2: a safe deployment path Set up continuous integration, a staging environment and a repeatable deploy. Add tests around the parts of the product you can least afford to break, such as sign-in, payments and anything that touches user data. You do not need full coverage. You need a net under the worst places. ### Week 3: ship something small Pick a minor fix or low-risk feature and release it end to end. Not because it matters to your roadmap, but because it proves the pipeline works and shows you how the team communicates. Watch how they handle a surprise. That tells you more than a pitch deck. ### Week 4: re-plan with real information By now the new team has seen the whole codebase in motion. Ask for a revised roadmap, with ranges, assumptions and the top risks. Compare it against the audit estimates. If they are wildly different, ask why. Then set a rhythm: a weekly demo of working software, a shared board you can read, and a monthly look at budget against progress. ![Laptop with code editor open on a desk as a new development team begins working on a handed-off project](https://images.unsplash.com/photo-1517694712202-14dd9538aa97?w=800&q=80) ## What a Bad Handoff Looks Like You can spot a bad handoff early. These are the patterns I see most, and each one is a reason to slow down and fix it before moving forward. - **The repository arrives as a zip file.** No history, no branches, no tags. You have the code but none of the reasoning in the commit log. - **Accounts are still in the agency's name.** Everything works until they close an account, change a billing card or stop answering email. Then your app goes dark. - **Only the agency can deploy.** If a release needs one specific person and a laptop only they own, you have not received a product. You have received a dependency. - **The secrets are in chat messages.** Passwords pasted into Slack or email, with no rotation afterwards. Assume they are compromised. - **No environment files, no seed data, no backups.** The code runs on their machine and nowhere else. - **The app is in someone else's developer account.** This is the hardest one to reverse, because app store transfers have conditions and take time. Verify it in week one. - **The new team keeps finding surprises.** A few are normal. A new one every day means the audit missed something or the handoff was thin. Pause feature work and go back to stabilizing. - **A rebuild nobody scoped.** The new team says they will fix the old code, then quietly starts rewriting it, and the budget doubles. Write the continue-or-rebuild decision down, with a number, and revisit it deliberately. Most of these are preventable if you take ownership of the accounts early and make the closing package a written condition of the exit. They are also the most common reason a switch that should have taken six weeks takes six months. ## Make the Switch in Order The sequence is simple and the order is the whole trick. Secure access. Pay for an audit. Decide to continue or rebuild with evidence. Read the contract with a lawyer. Give notice with a closing package attached. Run the knowledge transfer. Spend the first month stabilizing before you chase features. Skip a step and you take on risk that a calm week of preparation would have removed. Switching agencies mid-project hurts, and founders recover from it all the time. Plenty of good products were rescued from a bad first build, and the founders who pulled it off had one thing in common: they acted while they still held the keys. If you are weighing a switch right now and want a second opinion on the code, the contract or the plan, [Book a free strategy call](/get-started) --- *Originally published on [Kanopy Labs](https://kanopylabs.com/blog/how-to-switch-dev-agencies-mid-project)*