Software Project Takeover and Rescue
Your developer or agency left, ghosted or failed, or you want to switch vendors mid-project. Here is what to secure first and how a new team takes over the code.
Reviewed by Igor Gazivoda, Founder & CEO of StepTo · Updated
What Should You Do First When Your Developer Leaves or Ghosts?
Secure your access before you look for a replacement: the code repositories, the hosting and cloud accounts, the domain, the credentials and a backup of the data, then ask for a written handover. A new team can only take over what you can open, so access comes first and everything else follows from it.
Step 1
Secure the repositories
Check that you are an owner or admin of the GitHub, GitLab or Bitbucket organisation, not only a collaborator. If the code sits in the developer's personal account, ask in writing for it to be transferred to an account your company owns.
Step 2
Take ownership of hosting and cloud accounts
List every account the product runs on, such as AWS, Azure, Google Cloud, Vercel, app-store consoles and email or payment providers. Make sure the billing owner is your company and that you hold an owner-level login.
Step 3
Control the domain and DNS
Look up who is the registrant of your domain and where DNS is managed. A domain registered to a former developer is one of the most common ways a business loses its website.
Step 4
Collect credentials and rotate them
Gather API keys, database passwords and third-party logins into a password manager you control, then change them once the outgoing person no longer needs access.
Step 5
Back up before anything changes
Copy the production database, uploaded files and the full repository history to a place only you control. Do this before anyone touches the live system.
Step 6
Ask for a written handover
Request the setup steps, environment variables, deployment process, third-party services and known issues in writing. A partial handover is still worth having, and the reply (or silence) is useful evidence later.
Step 7
Read your contract
Find the intellectual property clause, the notice period and any handover obligation in the agreement with the previous developer or agency. Have a lawyer review it if the relationship has turned into a dispute; this page is general guidance, not legal advice.
The developer ghosted guide covers this sequence in more detail, and the vendor transition plan is for the case where the relationship is still working well enough to hand over properly.
How Does a New Team Take Over an Existing Codebase?
A new team reads the code before it changes anything, reviews the risks and the tests, stabilises what is already live, and only then plans new work. The order matters: a team that starts building before it understands the system tends to add problems to a codebase that already has some.
Stage 1
Read the code first
Engineers get the repository running locally, trace how a request moves through the system, and map the services, databases and integrations around it. Nothing is changed in this step.
Stage 2
Review risks and tests
Next they look for what could hurt you: outdated or unsupported dependencies, secrets committed to the repository, missing access control, and how much of the behaviour is covered by automated tests.
Stage 3
Stabilise what is live
Before new features, the team makes the live product safe to work on: a repeatable deployment, monitoring, working backups, and fixes for anything that is currently failing for users.
Stage 4
Then plan the roadmap
With a working baseline and a clear list of risks, you and the team decide what to build, what to refactor and what, if anything, to rebuild.
How long each stage takes depends on the size and condition of the codebase, so be wary of any vendor that quotes a fixed duration before it has seen the code.
When Is It Better to Rebuild Than to Take Over?
Take over when the product is live and the code can be read, and consider a rebuild when the stack cannot be supported, the data model no longer fits the business, or the product never launched. Decide after someone has read the code, not before, because the condition of the code is what the choice depends on.
| If this is true | It usually means |
|---|---|
| The product is live, users depend on it and the code is readable | Take over and keep building. A rewrite would put a working product at risk for no gain. |
| The code works but has no tests and no documentation | Take over, then add tests around the parts you change and write the documentation as you go. |
| Nobody can run the project locally or deploy it | Take over first to recover a working build, then decide. Do not choose a rebuild before the code has been read. |
| The language or framework is end-of-life, or the stack is so unusual that few engineers know it | Plan a gradual migration of the affected parts, or a rebuild if the stack cannot be supported at all. |
| The data model contradicts how the business now works | Rebuild the core and keep the parts that are still sound, such as the interface and integrations. |
| Security problems run through the whole codebase, not just a few places | Close the urgent exposures straight away. If the weakness is structural, price a rebuild against a repair. |
| The product never launched and the code is mostly a prototype | A rebuild is usually worth pricing against a repair, because there is no live system to protect. |
How Does StepTo Start a Takeover?
StepTo starts with a 15-minute call, then reviews the existing code and the access you hold, and proposes one of its engagement models. Engineers start 2-4 weeks after the first call, and an NDA, a data processing agreement and IP assignment terms are signed before any work begins.
The engagement models are staff augmentation from $4,500 per developer per month, a dedicated team of three engineers from $13,500 per month, and fixed-scope project work from $9,000. The first two weeks are a paid trial on real work, and StepTo replaces an engineer free of charge if the fit is wrong within 30 days. Which model suits you depends on the state of the product: one or two engineers can stabilise and maintain a small application, a team of three suits a product that also needs new features, and project work suits a defined piece such as a migration or a rebuild of one module. Full terms are on the pricing page.
What Are the Four Steps of an Engagement With StepTo?
An engagement with StepTo starts in four steps, whether you add individual engineers or a dedicated team.
Step 1
First call
A first call with StepTo about the roles, stack and seniority you need.
Step 2
Engineers join in 2-4 weeks
StepTo engineers join your team 2-4 weeks after the first call.
Step 3
Two-week paid trial
The first two weeks are a paid trial on real work, before you commit to the full term.
Step 4
Free replacement within 30 days
If an engineer is not the right fit within the first 30 days, StepTo replaces them at no extra cost.
StepTo staff augmentation starts from $4,500 per developer per month, with a 3-month minimum, weekly billing and a 30-day notice period to scale down; a dedicated team of three engineers starts from $13,500 per month, billed monthly. There is no recruitment fee; full terms are on the pricing page.
What Should You Ask a Vendor Before You Hand Over Your Code?
Ask who will read your code, where the work will happen, who owns the result, what the vendor needs from you, what happens when an engineer leaves, whether it has worked on an existing codebase before, and how the engagement ends. Ask every vendor the same questions and compare the answers side by side.
Who will read my code first, and will I meet those engineers?
The people who assess the project should be the people who work on it, not only the people on the sales call.
Will the work happen in my repository and my cloud accounts?
A vendor that keeps the only copy of your code or the only login to your servers recreates the problem you are trying to leave.
Who owns the code, and from when?
Ask for the intellectual property terms in writing before any work starts, and check that they cover code written on top of the existing codebase.
What do you need from me to begin?
A clear list of required access, documents and decisions shows the vendor has done this before.
What happens if an engineer leaves or is not the right fit?
Replacement terms and notice periods decide how exposed you are to the same failure a second time.
Can I see work on an existing codebase and speak to a past client?
Taking over code is a different skill from building from scratch. Ask for examples and references.
How does the engagement end, and what do I receive?
Agree the handover, documentation and access transfer at the start, while the relationship is good.
To score shortlisted vendors on the same criteria, use the vendor evaluation scorecard. For other providers StepTo is compared with, see software outsourcing alternatives.
Has StepTo Worked on Legacy Systems That Were Already Live?
Two of StepTo's case studies started from a legacy system. For a Dutch retail platform, page load time (LCP) dropped from 8.2 seconds to 0.5 seconds and the conversion rate rose 31%. For a Lithuanian payments fintech, reconciliation time fell 18×, from 3 days to under 4 hours. Both are measured results, linked below with the full detail.
E-Commerce · Series B Retail SaaS, Netherlands
E-Commerce Platform Rebuild
+31%
conversion rate · StepTo team: 6 engineers · 24 weeks
- LCP dropped from 8.2 seconds to 0.5 seconds (94% faster)
- conversion rate increased by 31%
- release cadence improved from bi-monthly to weekly (3× faster)
B2B SaaS · Series A SaaS Startup, Germany
Dedicated React Team: Shipping in 5-Day Cycles
5 days
feature cycle · StepTo team: 4 React engineers + 1 tech lead · 18 months (ongoing)
- 14 features in their first quarter, up from 3 in the prior quarter
- Time-to-feature dropped from 3 weeks to 5 days
AI / ML · Series B B2B SaaS Platform
AI Support Automation with RAG
70%
faster first response · StepTo team: 3 engineers · 4 months
- first-response time dropped 70% (from ~5.5 hours to under 100 minutes)
- 38% of tier-1 tickets were fully auto-resolved with no human touch
- average handle time for tickets still requiring a human agent fell 45%
Fintech · Series B Payments Fintech, Lithuania
Fintech Payments Compliance Rebuild
18×
faster reconciliation · StepTo team: 4 engineers · 5 months
- recertification passed on schedule with zero critical findings
- reconciliation time cut 18× (from 3 days to under 4 hours)
- reconciliation discrepancies down 92%
What Do Buyers Ask When Taking Over a Software Project?
Can a new team take over a project that has no documentation?
Yes. Documentation helps, but it is not a precondition. The running system, the code and the database are the source of truth: engineers read the code, run it, and write the missing documentation as they learn how it works. A written handover from the outgoing developer shortens the process, so ask for one even if it is partial.
Who owns the code after a takeover?
Ownership of the existing code depends on the contract with the previous developer or agency, so confirm what it says about intellectual property before you commit to anything. For work StepTo does, IP assignment is signed before any work begins. If ownership of the existing code is disputed, ask a lawyer; this is general guidance, not legal advice.
How long does a takeover take?
It depends on the size and condition of the codebase, how much access you already hold, and whether the product is live. A small, readable application is a different job from a large one with no tests. StepTo engineers start 2-4 weeks after the first call, and a review of the code is what turns the open questions into a plan.
What does a takeover cost?
There is no separate takeover fee on the price list. StepTo staff augmentation starts from $4,500 per developer per month, a dedicated team of three engineers from $13,500 per month, and fixed-scope project work from $9,000. The first two weeks are a paid trial on real work. The right model depends on whether you need to stabilise a live product, keep building it, or rebuild part of it.
What if the previous developer still holds the accounts?
Ask for a transfer in writing and name the accounts: repositories, hosting, domain registrar, app-store and third-party services. Most platforms have an ownership-transfer or account-recovery process for the registered billing holder, and your contract may oblige the developer to hand over access. Do not try to enter an account you have no right to use. If the developer refuses or goes silent, take legal advice before taking further steps.
Do you sign an NDA before looking at our code?
Yes. StepTo signs an NDA, a data processing agreement and IP assignment terms before any work begins, which means before an engineer opens your repository.
Can I speak to a past client before I hand over my code?
Yes, on request and under NDA. StepTo's published case studies are on the work page, and a reference conversation with a past client can be arranged.
Can I try StepTo before committing to a longer term?
The first two weeks of an engagement are a paid trial on real work, before you commit to the full term. If an engineer is not the right fit within the first 30 days, StepTo replaces them at no extra cost.
Ready to Get Your Software Project Moving Again?
Book a 15-minute call to talk through where the project stands, or send the details and StepTo will get back to you within one business day.
Let's talk about your project
Tell us what you're building and we'll get back to you within one business day with a no-obligation assessment.
Office hours
Send us a message
StepTo's Belgrade team replies within one business day.
