To take over a software project, secure the accounts and the ownership first, prove you can build and deploy the app without the previous developer, and have the code reviewed before anyone changes it. Only then plan fixes or new features. This guide puts those steps in order for the first 14 days, for a founder whose developer or agency has left and for the developer who inherits the code.
The order matters because the expensive mistakes happen early. A new developer who starts "fixing" on day one can break the one flow that still earns money, and an account still in the old agency's name can stop you shipping for weeks.
Day 1 and 2: recover access and put every account in your name
Make a list of every place the product lives, then check that your company, not the previous developer, controls each one. "We have the password" is not control: control means the account is owned by your company, billed to your card and has at least two named people from your side with admin rights.
| Asset | Where it usually lives | How to check you control it |
|---|---|---|
| Source code | GitHub, GitLab or Bitbucket | The repository sits in your organisation, with full history and every branch, not a zip |
| Hosting and cloud | AWS, Google Cloud, Azure, Vercel, a VPS | Your company is the account owner and the billing is on your card |
| Database and backups | The cloud account or a managed database | You can see a recent backup and someone has restored it once |
| Domain | The registrar | The registration is in your company's name and you can log in |
| DNS and certificates | Cloudflare, the registrar or the host | You can edit records; certificates renew automatically or you know when they expire |
| Email sending | Postmark, SendGrid, SES and similar | The sending domain and API keys are in your account |
| Payments | Stripe, PayPal, app store billing | The merchant account is yours and payouts go to your bank |
| Mobile apps | Apple App Store Connect, Google Play Console | The apps sit in your developer account, and you hold the signing keys or know where they are |
| Monitoring and analytics | Error tracking, uptime checks, analytics | Alerts go to your people, not to the old team |
| Third-party APIs | Maps, AI providers, SMS, search | Each key belongs to an account you own |
| Build and deploy | CI/CD service, deploy scripts | The pipeline runs from your repository with secrets you can rotate |
| Design and planning | Figma, the backlog, the bug tracker | You own the workspace, not a guest invite |
If an app is still in the previous developer's store account, both stores let the account holder move it to yours. Apple's app transfer keeps the app's reviews and ratings, and users keep receiving updates (App Store Connect Help). Google Play takes a transfer request from the original account (Play Console Help).
If the previous developer is still on speaking terms, ask for a recorded walkthrough of the deploy, the data and the parts they consider fragile before their access ends, and keep a written list of your questions and their answers.
Once you control an account, change every secret the old team knew: passwords, API keys, database credentials and deploy tokens. Turn on two-factor sign-in for every admin, then remove the previous developer's access. Check the repository history too. A key committed once is still readable in old commits, and GitHub's own advice is to revoke or rotate a leaked secret as the first step, because rewriting history alone does not make it safe (GitHub Docs).
Day 1 and 2, in parallel: get the code assigned to you in writing
Paying for software does not by itself make you the legal owner of its copyright. In both the US and the UK, the default owner of code written by a freelancer or an agency is whoever wrote it, unless there is a signed assignment.
- United States. A transfer of copyright ownership "is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed" (17 U.S.C. § 204(a)). Work an employee does within the scope of their job is "work made for hire" and belongs to the employer. Commissioned work only counts as work made for hire if it falls into one of nine listed categories and both sides sign a written agreement saying so (17 U.S.C. § 101). Custom software written by a contractor rarely fits those categories cleanly, which is why a signed assignment is the safer route.
- United Kingdom. "The author of a work is the first owner of any copyright in it", and work made by an employee in the course of their employment belongs to the employer (CDPA 1988, section 11). Computer programs are literary works under section 3. "An assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor" (section 90(3)).
So read your contract for an assignment clause. If it has none, ask the outgoing developer or agency to sign an assignment of the code as part of the handover, while the relationship is still friendly. This is general information, not legal advice: an attorney or solicitor can tell you where you stand under your own contract. UK readers will find more on agencies that have gone into administration on our software project rescue page for UK teams.
Day 3 to 5: prove you can build and deploy without them
This test shows whether the project still depends on the previous developer. Someone who has never touched the project takes a clean copy of the repository and tries to ship a release with nothing but the written instructions.
- Clone the repository on a fresh machine and install the dependencies from the lockfile.
- Build the app and run the tests that exist.
- Deploy it to a new staging environment, using secrets you created.
- Restore a copy of the latest backup into that staging database.
- Make a trivial visible change, such as a line of text, and release it to staging the same way production is released.
Every step that fails is a dependency on the previous developer: a script on their laptop, an environment variable nobody wrote down, a manual step in the release. Write each one down. Fixing them comes first in the plan, because until this test passes the project can only move as fast as someone else's memory.
Day 3 to 5: list what the app actually does
Next, find out what the product does today, not what the specification promised. Run every flow a customer or an admin uses and mark each feature with one of four states.
| State | What it means | Example |
|---|---|---|
| Working | Does the job end to end with real data | Sign-up sends the welcome email and the account works |
| Partly working | Works on the happy path, fails on edge cases | Payment works, but refunds never update the order |
| Mocked | Looks finished, but the data is fake or hard-coded | A dashboard showing sample numbers |
| Missing | In the plan or the contract, not in the code | The admin export that was agreed in the scope |
Include the parts nobody sees: scheduled jobs, webhooks, emails, background workers and admin tools. This list becomes the basis for pricing the remaining work, and it often settles arguments about what was delivered.
Day 6 to 10: audit the code before anyone changes it
With access secured and the build reproducible, have the code reviewed by someone who did not write it. A useful review covers at least:
- Security basics: exposed keys, unchecked inputs, weak access control, and outdated packages with known problems.
- Data: the database structure, migrations, backups, and where personal or payment data is stored.
- Access control: whether one customer can see or change another customer's data.
- Tests: what is covered, and above all whether sign-up, payment and other money flows are tested.
- Deployment: how releases happen, where secrets live, and how to roll back.
- Architecture: duplicated logic and choices that will make every change slower.
The output should be written, ranked by risk, and specific enough to hand to any developer. Our code audit does this for a fixed US$399 per app and repository, with the report in 3 business days, and the sample code audit report shows the format. If you are comparing prices, see how much a code audit costs.
Day 11 to 14: decide fix, finish or rebuild, one part at a time
A takeover rarely needs a full rewrite. Make the decision per area, not for the whole codebase, using what the first ten days found.
| Verdict | Signs that point to it |
|---|---|
| Keep | It works, it is readable, and the audit found no serious risk |
| Fix in place | The structure is sound, but there are specific bugs, gaps in access control or missing tests |
| Rebuild that part | Nobody can run or change it safely, the core logic cannot be followed, or the security model is wrong at the root |
Then sequence the work: the failures from the deploy test first, then the critical audit findings, then the features marked partly working, and only after that anything new. Price the plan from the feature list rather than from a guess, so the next phase has a fixed scope.
If the previous developer will not hand over
Start from what you do have. A deployed site, a partial copy of the code, app store listings or old emails with access details all help a new developer reconstruct the project.
- Read the contract for what it says about ownership, handover and notice.
- Ask in writing, with a specific list: the repository, each account from the table above, and a signed assignment of the code.
- Recover what you can control yourself first, usually the domain and the cloud billing, because those can take the product offline.
- If the agency has closed or gone into an insolvency process, the request goes to whoever now controls its assets. In the UK that is the administrator or liquidator, who takes control of the company's property (Insolvency Act 1986, Schedule B1 paragraph 67).
Where there is a dispute, a lawyer is the right next step. Technically, a review of what you hold tells you what can be recovered and what would need rebuilding, which is useful in that conversation too. If all you have is a live URL or a partial copy, send it for a free review and we reply in writing with what can be recovered.
If the app was built with AI tools
Projects started in Lovable, Bolt, Replit, Cursor or v0 follow the same order, with two extra checks. First, get the code into a repository you own: some builders keep the project, its secrets and even its database inside their own workspace until you export it. Second, look hard at access control and secrets, because generated front ends often talk straight to the database or carry keys in browser code. Our vibe coding cleanup page lists what each tool tends to leave behind.
For the developer who inherits the code
If you are the person taking over, the same order protects you as well as the client.
- Read the git history before the code: recent commits show what was changing and where the problems were.
- Get it running locally and in staging before you change anything, and write down every step that was not documented.
- Add tests around sign-up, payment and any other money flow first, so your changes cannot break them unnoticed.
- Start with small fixes to learn the code, and keep a list of risks you find, with dates. If something old fails later, the list shows it was there before you.
How we take over a software project
We follow this order on every software project rescue. You send the repository link or the app URL and a few lines on what happened, and we reply in writing within 1 business day with what we see and what we would do first. The free review has no sales call. If you go ahead, the US$399 audit produces the written report, and the remaining work gets a fixed quote you approve before it starts. The audit price is credited to that work if you book it within 30 days.
Acefina is led by Rai Ansar, a developer and DevOps engineer since May 2019. Our record under his lead includes more than 300 projects and 700+ site migrations without downtime.
Sources
All checked on 25 October 2026.
- 17 U.S.C. § 204(a), transfers of copyright ownership: law.cornell.edu
- 17 U.S.C. § 101, definition of a work made for hire: law.cornell.edu
- Copyright, Designs and Patents Act 1988, sections 3, 11 and 90: legislation.gov.uk
- Insolvency Act 1986, Schedule B1 paragraph 67: legislation.gov.uk
- Apple, overview of app transfer: developer.apple.com
- Google, transfer apps to a different developer account: support.google.com
- GitHub, removing sensitive data from a repository: docs.github.com