You did not build this app. Maybe a contractor did, maybe a co-founder who has since left, maybe an agency whose retainer just ended — and now it is yours to run. The login works, the app loads, customers are using it. Then you go looking for how an integration is wired, or which environment variable controls the payment flow, and you realize there is no documentation and no one left to ask. A Base44 app handoff that is just a shared password is not a handoff. It is a deferred emergency.
A proper Base44 app handoff transfers six things, not just a login: account access with confirmed ownership transfer, a schema and data-model map of every entity, the full set of environment variables and secrets, an integrations inventory with every key and webhook, a known-issues log of what is broken or fragile, and an operational runbook for deploys and recovery. Anything less forces whoever inherits the app to reverse-engineer knowledge that already existed, which is slower and riskier than the original build was. Capture all six while the original builder is still reachable and cooperative — once they are gone, the undocumented knowledge in their head leaves with them, and you are left rebuilding it.
What a Base44 Developer Handoff Actually Transfers
When founders ask me what a Base44 developer handoff should contain, they expect a code dump and a login. That is the smallest part of it. The code is visible in the platform; what is invisible — and what determines whether you can operate the app — is the layer of decisions, keys, and known fragilities in the builder's head. Across the 100+ Base44 apps we have shipped, audited, or rescued, the difference between a smooth inheritance and a six-week archaeology project is whether six specific artifacts were captured before that person walked away.
Those six: access and ownership, the data model, secrets and environment variables, the integrations inventory, the known-issues log, and the runbook. Each answers a question the new owner will be forced to ask, and skipping any defers the work to a worse moment — a production incident. This is the discovery work the lead engineer at Base44Devs runs at the start of every takeover, and exactly what a pre-takeover Base44 app audit is built to produce.
| Handoff artifact | Question it answers | Cost of skipping it |
|---|---|---|
| Access & ownership | Who controls the account and can I be locked out? | Losing your own product to a departed login |
| Data model / schema | What entities exist and how do they relate? | Breaking data on the first edit |
| Secrets & env vars | What keys make this thing run? | Silent failure when a key rotates |
| Integrations inventory | What is connected to the outside world? | An invisible integration dies unnoticed |
| Known-issues log | What is already broken or fragile? | Re-discovering every bug the hard way |
| Runbook | How do I deploy, recover, and operate it? | Panic during the first incident |
Step One: Account Access and Ownership Transfer
Before schema or secrets, settle who actually owns the Base44 account — the failure mode that locks founders out of their own product. On a worrying number of inherited apps, the app does not live under the company's account at all; it lives under the previous developer's personal login, and the founder only ever had a workspace invite. The day that developer revokes access, you do not own a fragile app, you own nothing.
So step one is transferring true ownership: the app must sit under an account you control, with billing tied to your card, and you must hold the owner role, not an editor seat. Do this while the previous developer is cooperative, because after a relationship sours it gets hard to extract. While you are in there, document every person with access and their level — orphaned editor seats from a long-gone contractor are both a security hole and a source of mysterious changes. If ownership is contested or the builder has gone dark, that is what we handle when you hire a Base44 developer.
Step Two: Map the Schema and Data Model
Once you control the account, the most valuable capture is the data model, because it is the thing most likely to break catastrophically on a careless edit. A Base44 app is its entities — Users, Orders, Subscriptions — and the relationships between them. The builder knew that an Order references a Customer and that deleting a customer should not orphan their orders. None of that intent is obvious from the app, and the AI agent does not reliably preserve those relationships when it regenerates a screen.
Your handoff needs a plain-language map of every entity, its key fields, and how it connects to the others. We write it as sentences a non-technical owner can read: "A Subscription belongs to one User; cancelling it sets status to cancelled, never deletes the record, because billing history depends on it." That prevents the most common post-handoff disaster, where someone asks the agent to "clean up old data" and it deletes records other parts of the app depend on. If your inherited data already looks inconsistent, the schema was likely never documented and the agent has been quietly drifting it — one reason an audit pays for itself before you touch anything.
Step Three: Secrets, Environment Variables, and Integrations Inventory
Here is the part that silently ends apps: the secrets and integrations that make the thing work exist only in the live environment. The app runs today because a Stripe key, a SendGrid key, an OpenAI key, and a half-dozen environment variables are set in production — not in any document or anyone's notes. The day one rotates or expires, an integration dies, and the new owner has no record of what was connected, let alone how to fix it.
Capture two inventories. First, every environment variable: name, what it controls, where its value comes from. Second, every external integration: the service, what it does, which keys it uses, and — critically — every webhook endpoint and where it points. Webhooks are the most-missed item in every handoff I have reviewed: configured on the third-party side, invisible from inside Base44.
| Inventory item | What to record | Why it bites later |
|---|---|---|
| Environment variables | Name, purpose, source of value | Rotated key takes down a flow with no trace |
| API keys / secrets | Service, scope, owner of the account | Locked out when the original account closes |
| Webhook endpoints | Source service, URL, what it triggers | Configured off-platform, invisible, breaks silently |
| OAuth connections | Provider, scopes, refresh behavior | Tokens expire and no one knows why login broke |
| Scheduled jobs | What runs, when, and what it depends on | A nightly job fails unnoticed for weeks |
Treat this inventory as the load-bearing section of the handoff. An app with an undocumented webhook has a hidden tripwire — we have more than once diagnosed a "randomly broken" payment flow that was simply a webhook pointing at a key someone had rotated weeks earlier.
Step Four: The Known-Issues Log
Every inherited app has things that are broken, fragile, or held together with a workaround the previous builder knew about and you do not. The known-issues log captures that knowledge before it evaporates. It is the section people are most tempted to skip — admitting what is broken feels like admitting failure — and the one that saves the most time, because it stops the new owner from rediscovering every defect the painful way: through a customer complaint.
A good log records each issue, its severity, any workaround, and what triggers it. "The export button times out on accounts over 5,000 rows; tell those users to filter by date first" is worth more than a thousand lines of pristine code. So is "do not let the AI agent edit the checkout function — it strips the access check every time," a failure mode unique to AI-built apps that we see on nearly every takeover. If your app is genuinely half-finished rather than under-documented, the log doubles as the punch list, and our process for finishing a half-built Base44 app starts here.
Step Five: The Operational Runbook
The runbook answers the question you will ask at the worst possible time: something is broken in production, what do I do? It covers the operational reality of running the app — how changes get deployed, how to roll back a broken edit, where the data lives and how it is backed up, and who to call when a third-party service has an outage.
For a Base44 app, the runbook must address the platform's signature risk: the AI agent will, on an unrelated prompt, regenerate a function and discard logic it deems irrelevant. So the runbook records which functions are frozen and must never be edited by the agent without a human reviewing the diff, plus the deploy-and-test ritual — what to verify before a change is live, and how to recover if it is not. This is the discipline we provide continuously under a Base44 app ongoing support retainer; the runbook lets a new owner operate safely before that support is in place.
The Copy-Paste Handoff Checklist Template
This is the actual Base44 app documentation template we work from — copy it, fill every row, and you have a handoff that survives the original builder leaving. The discipline is finishing every line. The integrations inventory and the known-issues log are the two sections everyone shortcuts, and the two that cause the most damage.
| Section | Item to capture | Done? |
|---|---|---|
| Access | Owner-level account login under your control | ☐ |
| Access | Billing tied to your payment method | ☐ |
| Access | Full list of users and their access levels | ☐ |
| Schema | Every entity, its key fields, and relationships | ☐ |
| Schema | Delete/cancel rules that protect dependent data | ☐ |
| Secrets | Every environment variable, purpose, and source | ☐ |
| Secrets | Every API key, the service, and account owner | ☐ |
| Integrations | Each external service and what it does | ☐ |
| Integrations | Every webhook endpoint and where it points | ☐ |
| Integrations | OAuth connections and scheduled jobs | ☐ |
| Known issues | Each bug, severity, trigger, and workaround | ☐ |
| Known issues | Functions the AI agent must never regenerate | ☐ |
| Runbook | Deploy and rollback procedure | ☐ |
| Runbook | Backup location and recovery steps | ☐ |
| Runbook | Third-party support contacts and escalation | ☐ |
If you can tick every box, you have a real handoff. If you cannot, the unticked boxes are precisely your risk surface — where the app depends on knowledge that lives nowhere. When vetting whoever does this work, our Base44 developer vetting guide covers the questions that separate someone who documents from someone who hands you a password.
When to Bring in an Audit Before You Take Over
A handoff tells you what the previous developer chose to write down. An audit tells you what is actually true — including what they did not know or did not want to mention. That gap matters most right before you take ownership: once the app is yours, its security holes, broken integrations, and fragile AI-generated code become your liability.
| Handoff scenario | Right move | Investment |
|---|---|---|
| Builder cooperative, app healthy | Fill the template together | Time only |
| Builder gone, app a black box | Pre-takeover audit to map it | $497, 1 business day |
| Audit surfaces live bugs | Fix sprint in parallel | From $1,500, 48-72h |
| App half-finished | Audit, then complete the build | Build from $4,500 |
| Ongoing operation after handoff | Support retainer | Monthly retainer |
Our $497 audit delivers in one business day and doubles as the first half of a handoff document: it maps the schema, surfaces undocumented integrations, flags security gaps, and produces the known-issues log a hurried handoff omits. If it turns up live bugs, a fix sprint from $1,500 runs in 48-72 hours. Still deciding whether the app needs dedicated help? Our piece on whether you need a developer for your Base44 app frames that call. When you are ready to inherit a documented app instead of a mystery, book a free 15-minute scoping call and we will tell you what your handoff is missing.
Related reading
- Base44 app ongoing support retainer — operating the app safely after the handoff.
- Do I need a developer for my Base44 app? — whether an inherited app needs dedicated help.
- Finish my half-built Base44 app — when the handoff reveals the app was never completed.