Who looks after the app when the person who built it leaves?
A colleague, an outside developer or we can, if the company holds the accounts, code, keys and access. If the builder holds them, the app leaves with them.
For owners, heads of department and IT. The handover list below works without Fabrika too.
Updated 22 October 2026
“The question is whether developing apps that are critical to how a company runs and grows can rest on one irreplaceable person.”
“Building an app is one thing. Making sure it works for five years is another.”
What happens when the builder leaves?
At first, nothing. The trouble comes in three steps.
- 01 The first weeks
The app keeps running
Nobody notices that no one stands behind it, because nothing has needed changing yet.
- 02 The first change
Someone wants something adjusted
A new field, a new approver. Nobody knows where the code is or who can sign in.
- 03 The first outage
The app stops working
A card expires or a trial ends. The data sits on someone else's account.
Where the keys to the app usually are
Not on purpose, it was just quickest.
- The tool account (Lovable, Replit, Bolt) on the builder's private email.
- The database, often Supabase or Firebase, on their account and card.
- The repository on their personal GitHub, or none at all.
- The domain, in their name.
- Keys to AI, email or payments in a
.envfile on their laptop. - The only admin account in the app.
- Why things are built this way: in their head and AI chat history.
What should you sort out before they leave?
With the builder around, it's a few hours of work together. After they've gone, it takes weeks, and some things never turn up.
Accounts and ownership
-
01 List every service the app depends on.
Tool, hosting, database, domain, email, payments, AI. Forgotten ones show up on the card statement and in
.env.example. -
02 Move the accounts into the company's name.
Move projects into company organisations (GitHub, Supabase, Vercel); elsewhere switch the account email to a shared company inbox.
Code
-
03 Is the code in a repository the company owns?
Transfer it to the company's GitHub and check it holds the running version: Lovable or Replit only push there when the connection is on.
-
04 Can the code be got out at all?
Bubble and similar tools export only the structure and data, not the code. At least download the data and write down what the app does.
Keys and passwords
-
05 List the keys and passwords the app depends on.
Which service, whose account, where stored. Values go in the company password manager, not email.
-
06 Agree to replace the keys on their last day.
The builder may still have them saved, without any bad intent. Generate new keys on company accounts and revoke the old ones.
Where it runs
-
07 Where does the app run, and how does a new version go live?
Have the builder show someone the deploy once, not just describe it.
-
08 Is the database backed up, and has anyone tried a restore?
Where are the backups, how often, on whose account? Treat a backup nobody has restored from as uncertain.
Who pays
-
09 Whose card is it all running on?
Move every service to a company card or invoice, and check trial plans and when the domain renews. An app on a private card ends with the first failed payment.
Documentation
-
10 One page in the repository is enough.
What it's for, which services, how to run and deploy it, what broke before, what's half done. Put it in the
README. -
11 The instructions the AI built from.
Make sure files like
AGENTS.md,CLAUDE.mdor.cursorrulesare in the repository. The next person and their AI pick up from them.
Access
-
12 Do at least two people in the company have admin access?
In the app and the services behind it. Add the second admin before closing the builder's account, or you'll be locked out.
-
13 Who owns the app, and who will maintain it?
The owner decides what it does and for whom, the maintainer keeps it running. Always a specific name, not “IT”.
-
14 A list of where to remove their access on the last day.
With company sign-in, closing their account is enough. With the app's own passwords, go through the app, tool, repository, hosting, database and domain.
Before the app goes to more colleagues, go through the production checklist too.
They've already left. What do you do on day one, and in the first week?
It can be done without them, just slower.
Don't make it worse
- Don't switch off or delete anything. The running app is now the best documentation of what it does.
- Remove their access everywhere you can, but keep their company inbox and give someone access to it: password resets will land there.
- Export the data, at least into a spreadsheet.
- Write to them with a specific list: accounts, repository, keys, half an hour for questions.
Bring it back under the company
- List the services from card statements, invoices and the code.
- Get the code into a company repository. If it can't be got from the tool, count on rebuilding the app.
- Replace the keys and passwords you can reach, payments and data access first.
- Open the app in a private window; if you get in without signing in, fix it now. See the production checklist.
- Decide whether you still need the app, and who takes it over: a colleague, an outside developer or Fabrika.
The accounts are on a private email and the builder isn't responding
Some services transfer an account once you prove the app is the company's. Who owns the code depends on the employment or supplier contract, which is a question for a lawyer.
What does it look like on Fabrika?
On Fabrika, the platform your company builds its apps on, sign-in, access and keys don't depend on the builder, so most of the handover list is covered from the start.
The accounts are the company's
Apps run in a cloud account in your company's name, usually on Zerops. You pay for servers directly, by usage.
The code is in the company's Git
Each app has a repository in your name and goes live only from there, with every deploy recorded.
Keys aren't in the code or in anyone's head
The cloud provider holds them. Each app sees only its own; they can be written, never read back.
Access hangs on the company account
Company sign-in through your identity provider (e.g. Entra ID, Okta). Without SCIM sync yet, we also disable leavers in Fabrika's IAM, ending their sessions.
We've seen every change
We review each change before it goes live and report what changed and what we checked.
Anyone can pick it up
A colleague, a developer, an agency or us, straight from Git, and we help them find their feet. Small edits your people can also make through their own Claude or ChatGPT.
The platform watches operations
Errors from all apps in one place, uptime checks and alerts. Backups and recovery we set up with you.
And if we ever stopped
Code, data and domains are yours, in your account, and the platform is open source. The system keeps running without us.
What stays with you
An owner for each app. Your people's company accounts and closing them. Who gets which role.
When is it better to let the app go?
- Nobody has opened it in the month since the builder left. Export the data, switch it off and cancel the services.
- It was one person's own tool and nothing depends on it.
- A ready-made tool does the same thing just as well for you.
- The code can't be got out and the process isn't critical. Rebuilding only pays off if the company relies on it.
When isn't Fabrika for you?
- Your own IT or developers can run apps and review changes. The handover list and tidy accounts are enough.
- The app lives in Bubble or a similar builder without code export. We can only rebuild it.
- Your IT requires Azure, your own servers or SAML-only sign-in. Fabrika runs on Zerops, or AWS on request, with OIDC sign-in.
- It's a public service for thousands of customers with payments and open sign-up.
- You want a one-off code check and will run the app yourselves. An audit is cheaper.
What people ask about looking after an app
Who actually maintains an app built with AI?
Until someone decides otherwise, the builder, often without leadership knowing. Maintaining means keeping it running, letting changes in, updating libraries, managing access and handling outages.
What has to be in the company's name before anyone else works on the app?
The service accounts, the repository, the payment card, the keys, and at least two admins from the company. Everything else can be tracked down later. These can't.
Who answers when something goes wrong inside the app?
Without an agreement, whoever happens to be around. On Fabrika we answer for operations under an SLA and fix bugs that show up in production, even in your developer's or agency's code. More in Your developers.
A colleague handed us an app built with AI to review and put into production. Can you help?
Yes, that's a takeover: we go through the app, make small changes so the platform handles sign-in and deploys, and deploy it to your cloud account. You're not alone: “they handed me a vibe coded app and asked me to review it for them and put it into production” (Hacker News, 2026). Details for IT on Security.
Isn't it enough for the builder to write documentation?
It helps, but if the accounts and the card are still theirs, the next person can't get in anyway. Ownership first, then the description.
The builder has left and we don't have the code. Can the app be taken over?
From Lovable or Replit, yes, if you can get into the account. From Bubble and similar tools, it can only be rebuilt. We'll tell you which case yours is on the scoping call.
Can we keep building in Lovable after the takeover?
We're checking that now; ask us how far we've got. What's certain is that your person can keep building with Claude Code or Codex. More on Lovable apps.
How much does it cost?
A one-off Fabrika setup, then monthly operations with change review. You get the price in an offer after the scoping call, before we start, never per user or per hour. More in Pricing.
Show us the app.
Half an hour and a link to the app or the repository, even if the builder has already left. We'll go through what's in the company's name and say what a takeover onto Fabrika would involve, or that it doesn't make sense.