Give a developer taking over your app five things: named access at the level their work needs, business ownership of every core account, a verified system packet, live walkthroughs of the critical workflows, and proof they can build, deploy, roll back, answer an alert and restore data on their own.
A repository invitation and product tour are not a transfer. The developer needs enough business context to know what must not change, enough technical context to find the relevant systems, and enough operational access to respond without waiting for the founder to reconstruct every step.
The packet to hand over
Business and boundaries
- Name the main business workflow, the people who rely on it, and the consequence if it stops.
- Mark which features are current, experimental, deprecated, or intentionally incomplete.
- List known failures, accepted risks, upcoming commitments, and changes that are explicitly off the list for now.
- Agree who approves releases, production data changes, spending, and customer communication.
Accounts and access
- Confirm the business retains owner access to the domain, source control, hosting, database, storage, payments, email, analytics, and app-store accounts.
- Give the developer their own account with the least privilege needed; do not share a founder login.
- Inventory production secrets by purpose and location without copying secret values into the packet.
- Define how access will be reviewed, escalated, rotated, and revoked.
System and code
- Record the production commit or artifact, runtime versions, package manager, build command, test command, and deployment path.
- Map the frontend, APIs, databases, storage, queues, scheduled jobs, identity, payments, and external integrations.
- Explain the critical data model, tenant or role boundaries, and migrations still in flight.
- Identify fragile areas and attach the test or procedure required before each change.
Operations and proof
- Demonstrate monitoring, alert delivery, logs, support escalation, status communication, backups, restore, rollback, and spend controls.
- Have the new developer run the app locally or in development, deploy safely, trigger a test alert, and complete the critical workflow.
- Record unresolved access or knowledge gaps with an owner and date.
- Keep the previous owner available for a defined overlap period, then remove access no longer required.
The checklist is deliberately split between transfer and proof. A document can say rollback works; done means the new developer performs the rollback, or a safe equivalent, without step-by-step rescue from the previous owner.
Keep ownership with the business
Moving core accounts into a developer’s personal control creates a new single point of failure. The business should own the domain, billing relationship, organization or workspace, repository, production data, and recovery methods. The developer receives a named role appropriate to the work.
Use separate identities and multi-factor authentication. Avoid shared passwords and long-lived all-powerful tokens. OWASP’s Secrets Management guidance recommends controlling access, documenting secret purpose and consumers, and supporting rotation and revocation across the secret lifecycle.
If a contractor or previous developer currently owns a core account, transfer it into a business-controlled organization before relying on the transfer. Verify billing, recovery email, MFA, administrator list, API ownership, and domain or app-store rights after the transfer.
Build the packet before the first sprint
The packet should reduce discovery time without pretending to replace direct inspection. Across the vibe-coded apps I’ve read that somebody else built, the single biggest time cost was reconstructing the intent that only ever lived in the original prompter’s head: why a table exists that nothing in the current UI seems to touch, which flow is load-bearing versus a leftover experiment, what was deliberately left half-built versus quietly forgotten. None of that shows up in a diff.
Every hour a developer spends guessing why your app works the way it does is billed twice: once when you built it, once now that someone else has to learn it.
| Packet section | What it must answer |
|---|---|
| One-page system overview | What the app does, who uses it, and which workflow matters most |
| Architecture and dependency map | Which runtime systems and external providers participate in that workflow |
| Environment and deployment map | Which environments exist, where configuration lives, and how a version reaches production |
| Data and access notes | Which records are authoritative, which roles exist, and where tenant boundaries are enforced |
| Operations runbook | How to detect, respond, rollback, restore, and communicate |
| Known-risks ledger | What is fragile, why it matters, what evidence exists, and what can wait |
| Decision record | Why unusual architecture or business-rule choices were made |
What real documentation for a vibe-coded app should actually contain is a deeper question, and a bigger job than this packet needs to take on. The packet is the minimum transfer view; durable documentation continues after the developer begins learning the system.
Do not paste production keys, customer exports, or passwords into the packet. Record the secret name, purpose, owner, storage system, consumers, rotation procedure, and required permission. Grant the value through the platform built to manage it.
Separate product intent from technical implementation
Generated code can show how a feature works without explaining why the business needs it. Capture the intent in plain language:
## Workflow: Approve a customer refund
- Who uses it:
- Business outcome:
- Rules that must remain true:
- Systems and data involved:
- Known edge cases:
- Test or evidence:
- Owner when it fails:Include a written spec the app was actually built against where one exists, and a rules file the next AI session reads before touching anything. The maintainability case for a rules file covers what an AI tool needs to stop breaking things; the packet is what a person needs to stop guessing. The spec records expected behavior; the rules file constrains future tool use; neither replaces tests or the packet a person reads.
Avoid reverse-engineering intent from variable names, comments, or old prompts alone. Label inferred intent as an inference and ask the business owner to confirm it. Old chat history can supply context, but it is rarely a clean, current specification.
Demonstrate the operating path
Google’s SRE engagement model describes onboarding as a progressive transfer of production responsibilities and recommends design overviews, request-flow deep dives, production setup, and hands-on exercises, with the previous team available during the transition. A small app can use the same structure without adopting a large-team process.
Schedule working sessions around concrete tasks:
- Trace one critical request from the interface through the server, data store, and external services.
- Deploy a harmless change through the normal pre-production and production path.
- Find the deployment in logs and monitoring, then roll it back or demonstrate the rollback procedure safely.
- Trigger a test error and follow the alert to the responsible person.
- Restore representative data in an isolated environment.
- Add, change, and revoke a team member’s access using named accounts.
Record gaps discovered during the walkthrough. “Only the founder can deploy” and “backup exists but restore needs an unknown key” are transfer findings, not reasons to improvise silently.
Developer onboarding when there is no engineering team
Most advice about onboarding software developers assumes an engineering manager, a platform team and a written ramp plan. Developer onboarding here is smaller and more personal: you are the only source of the context that matters, so three jobs land on you and nobody else can do them.
- Book the sessions instead of waiting to be asked. A developer who has to chase you for context will guess instead, and the guesses become code you live with. Put the walkthroughs in the calendar before their first day.
- Answer why, not how. They can read the code. They cannot read why the refund rule has an exception for one customer type, or why a table nothing seems to touch is still there. Every answer of that kind is time they do not spend reverse-engineering intent.
- Hand the work over in order. Start with something small and reversible inside the workflow that matters most, so the first change exercises the whole path: run it locally, review it, deploy it, find it in the logs, roll it back if needed.
A common failure when founders take on onboarding new developers themselves is silent drift. The developer is busy, the founder assumes progress, and the first honest check happens long after the direction was set. Ask for one visible result early and a visible result at a fixed cadence after that, so you learn how the transfer is really going while it is still cheap to correct.
Agree what done looks like before responsibility moves
The transfer is done when the new developer can run the agreed work independently, not when every document has a green check.
| Claim on paper | Proof it is true |
|---|---|
| The app is documented | The developer can locate and explain the critical request path and its dependencies |
| You have production access | A named account can perform the approved task and cannot perform excluded admin actions |
| Deployments are straightforward | The developer ships an identifiable commit through the agreed gate |
| Monitoring is configured | A test failure creates a useful alert in the right channel |
| Backups are enabled | Representative data is restored and usable in an isolated environment |
Write a responsibility matrix for the overlap period: who responds to incidents, approves changes, speaks to users, manages providers, and decides on risky data work. Set an end date and remove access that is no longer needed once the transfer is done.
The fix-list interview
Once the packet exists, the hiring interview gets shorter. Hand a serious candidate the packet plus read access, and ask for one thing back: a short, ordered list of what they’d fix in the first two weeks, with rough hours attached, instead of a verdict on whether the whole app should be thrown out. A rebuild opinion is cheap to hand out and expensive to act on, and the people most likely to offer one unprompted are, structurally, the same people who’d bill you to build it. Ask for the fix list anyway. An unprompted rebuild pitch is a data point about who profits from rebuilds, worth noting and weighing accordingly.
The fix list also tells you something the resume can’t: whether they read the fragility notes before saying anything. A candidate whose first list matches the areas you already flagged as fragile has actually read the packet. One whose list is generic, “add tests, clean up the code,” probably skimmed it.
Plan the first sprint around evidence
The first sprint should produce a baseline and prioritized work, not a verdict based on code style. Ask the developer to reproduce critical flows, run the existing checks, confirm production drift, inspect the highest-consequence boundaries, and return an ordered list with evidence, dependencies, estimates, and retest conditions.
In AxonBuild’s fixed June–July 2026 cohort, 22 of 26 audited apps had at least one confirmed-critical finding. That selected study is not a prediction about the app being handed over. It supports budgeting discovery time and prioritizing confirmed consequence over aesthetic cleanup. Most priorities trace back to whether an AI-built app is ready for people to rely on and which technical debt actually makes AI-generated code harder to change.
Do not choose a whole-app rebuild because files are long, AI generated, or unfamiliar. Consider repair, boundary replacement, or complete rebuild only after the current behavior, constraints, migration cost, and business deadline are understood.
Common questions about handing an app over to a developer
What should I give a developer taking over my app?
Give them named access, a system overview, architecture and dependency map, environment and deployment map, data and role notes, operations runbook, known-risks ledger, critical-flow tests, and decision context. Keep secret values in a secrets manager rather than the document.
Should the developer own my hosting and domain accounts?
Usually no. The business should retain owner and recovery access while the developer receives an appropriate named role. If the developer is becoming an internal technical owner, permissions may be broad, but business continuity should not depend on one person’s account.
How long should handing an app over to a developer take?
It depends on how big the system is, how good the documentation is, what access already exists, and how complicated operations are. Define completion through demonstrated tasks rather than a universal number of hours: build, deploy, alert response, critical-flow trace, rollback, restore, and independent access.
How much will it cost to fix my vibe-coded app?
Nobody can give you a number sight unseen, but the honest range starts from what similar apps needed: 22 of 26 audited apps had at least one confirmed critical to close before anything else, on top of the ordinary list of smaller gaps every one of them carried. Ask a candidate developer to price the fix list, not “fixing the app,” since the second phrasing invites a guess and the first invites an estimate.
Should the new developer rebuild a vibe-coded app?
Not by default. Ask for evidence showing why incremental repair or replacing one boundary cannot meet the requirements. Include data migration, feature parity, parallel operation, rollback, cost, and new-defect risk in the comparison.
How is a planned transfer different from inheriting an app cold?
A planned transfer moves current intent, access, procedures, and live demonstrations while the previous owner remains available. If you’re the one who inherited an app instead of handing one over, the sweep you need runs in a different order, beginning with control, evidence preservation, exposure, and recovery.
Still the only person who can keep the app moving?
When staff or customers depend on it, AxonBuild can fix the next failure, ship the next change, and document the app so progress no longer waits on you.
