The developer left. How to take over a live SaaS without breaking it

The application usually keeps running after the developer leaves.

That can make the handover look less urgent than it is. Customers can still log in, payments still move and the founder can still make small changes. Nothing appears broken enough to justify stopping.

The gap shows up later, when somebody needs to answer a question that used to live with the developer.

Which service sends the invoice email? Can this database migration be reversed? Why does the production deployment come from a branch nobody recognizes? Does the old contractor still have access?

Taking over the product is less about reading every line of code and more about restoring control in the right order.

Do not begin with a cleanup

An unfamiliar repository always contains things a new developer wants to reorganize. Ignore that feeling for the first few days.

Code style is not the immediate risk. Unknown access, unowned deployments, untested backups and undocumented commercial paths are.

The first rule is simple: change only what is necessary to establish control or contain an active problem. Keep ordinary feature work paused until the system map and release path are clear.

That pause does not need to last for weeks. It does need to be explicit. Otherwise the founder, a new contractor and an AI agent can all change the same product while nobody understands the current baseline.

First, recover the accounts

The handover starts outside the codebase.

List the accounts that can affect whether the product stays online:

• Domain registrar and DNS
• Source repository and organization ownership
• Hosting and deployment platform
• Database and file storage
• Authentication provider
• Payment provider
• Transactional email
• Monitoring and analytics
• Background job or queue provider
• Mobile store accounts, if the product has an app

For each account, record the legal or company owner, current administrators, billing owner, recovery method and whether the departing developer still has access.

Do not move everything into one founder account as a shortcut. The business should own the important systems, and individual people should receive the least access needed for their work.

Rotate credentials when there is a reason to believe they were shared or stored outside the company. Do it carefully. A secret can be used by production even when nobody remembers where it was configured.

Find the actual source of truth

The repository that looks official may not be the one production uses.

Start from the running application and trace backward:

1. Which platform serves the live domain?
2. Which project or application does that domain point to?
3. Which repository and branch produced the current deployment?
4. Which environment variables and connected services does it use?
5. Is the deployed commit present in the repository the company controls?

If the application was built in Bubble, Lovable, Base44 or another platform, the source of truth may be the platform project plus a connected repository. Write down both. The mistake is assuming an export or old GitHub repository contains everything needed to reproduce production.

Once the path is known, tag or record the current working version. That becomes the point you can compare future changes against.

Map the paths that make the business work

Do not map every screen with equal effort.

Start with the flows that would create a commercial problem if they failed quietly:

• Signup, login and password recovery
• Customer permissions and account separation
• Subscription creation, cancellation and entitlement changes
• The core job the customer pays the product to perform
• Imports, exports and scheduled work
• Transactional email and notifications
• Admin actions that can alter customer data

Trace each path across the interface, API, database, external vendors and background jobs. Write down where the work begins, where data changes and where a failure appears.

This becomes the critical-path map. It is much more useful during the takeover than a diagram containing every library and internal helper.

Prove the recovery route

A backup entry in a dashboard is useful evidence that a job ran. It is not evidence that the application can recover. The restore has to be tested.

The takeover needs answers to a few practical questions:

• What does the backup include?
• Are uploaded files included or only their database records?
• Which passwords, API keys and service settings must be recreated?
• Where can the backup be restored without touching production?
• How long does the restore and verification process take?
• Who can perform it without the former developer?

Run one restore in a separate environment. Open the application against it. Check a small set of known records and one commercially important flow.

The first test may fail. That is useful. A failed planned restore produces a list of missing instructions while customers are not waiting.

Build a release path before adding features

The new owner needs one documented route from a proposed change to production.

At minimum, define:

1. Where the change is made.
2. Which automated checks run.
3. Where a human can try the real flow before release.
4. Who approves consequential changes.
5. How production is deployed.
6. What signal confirms the release is healthy.
7. How to return to the previous working version.

For a small founder-led product, this can fit on one page. The process does not need enterprise ceremony. It needs enough structure that a new developer or coding agent can follow it without improvising around production.

Give AI instructions that survive the chat

Founders often keep using Codex, Claude or another agent during the handover. That can work well once the project carries its own rules.

Put persistent instructions in the repository or platform workspace:

• What the application does and which paths are commercially critical
• Which commands verify a change
• Which environments the agent may access
• Which files or systems require review
• Which facts the agent must never infer
• What evidence counts as done
• When the agent must stop and ask for a human decision

Persistent instructions stop the team from repeating the same production context in chats that disappear. A longer prompt on its own does not.

Decide what the product needs next

An inherited product does not automatically need a rewrite. That decision needs its own rescue-or-rebuild test.

After the access, system, critical-path and recovery maps exist, the next step is usually one of five things:

• Keep the current stack and document it.
• Stabilize one or two material risks.
• Put ongoing technical ownership around releases and decisions.
• Migrate a platform or subsystem in controlled phases.
• Hire a full-time senior engineer or CTO because the workload has become a full-time job.

The correct answer may be to spend less than the founder expected. It may also be to stop feature work for a defined repair. You can make that decision once the system is visible.

The 10-Day Production Takeover follows this order for one live application. It establishes control, fixes or contains one eligible material risk and hands back the maps, operating instructions and 90-day decision plan whether or not ongoing work follows.