KeelenAnswer — inherited codebase
My developer left and I cannot code. How do I keep my app going?
Updated 20 August 2026
Secure access first: make sure you own the GitHub organisation, the hosting account, the domain, and the app-store listings, and rotate any credential the person who left still holds. Then get the app provably buildable by someone other than them: a written setup guide, a working CI pipeline, and a test that proves the app boots. Only then decide who does the ongoing work: a new hire, an agency, a freelancer, or an autonomous dev loop such as Keelen, which works the repository continuously and gates every change on your tests and CI.
Do not start with features. An app nobody can build or deploy is an emergency, and it stays one until the pipeline works without the person who left.
What to do, in order
Take ownership of every account
GitHub organisation, hosting, domain registrar, database, error tracker, app-store listings, payment processor. Transfer ownership to an account you control, then rotate keys and revoke the departed person's access.
Prove the app can be built and deployed by someone else
If deploying depends on a laptop nobody has any more, that is the first thing to fix. A CI workflow that builds, tests, and deploys from a clean checkout is what converts tribal knowledge into something transferable.
Get a smoke test in place
One test that proves the app starts and the critical path works. It is the difference between changing code hopefully and changing it safely.
Commission a review of what you inherited
A repository-wide read of code, secrets in git history, dependencies, and infrastructure tells you what you actually own. Expect surprises in the secrets and dependency layers.
Choose the ongoing arrangement deliberately
A hire, an agency, a freelancer, or an autonomous loop. Pick on throughput versus accountability, and write down who decides what so the next handover is easier than this one.
Why the pipeline matters more than the code
The code is usually fine. What leaves with a departing developer is the knowledge of how to build, test, and deploy it. That is why the first work is a CI workflow and a setup guide rather than a feature: they make every subsequent option (hire, agency, or loop) possible at all.
What a loop can pick up
Keelen connects to the repository, detects the stack and the test command, and works from written requests. It is well suited to the work an unfamiliar codebase generates: adding tests, patching dependencies, fixing reported errors, and making small changes one reviewable pull request at a time. Five gates stand between the loop and your main branch. New tests are applied without the implementation first and must fail, so tests born green are rejected. An independent reviewer that shares no context with the run that wrote the code reviews the diff. Your own test suite runs on a clean checkout. Nothing merges over a red required CI check. And a review window stands before gated auto-merge, which you can replace with plan-review sign-off, manual merge, or branch-only mode.
Know what you inherited before you change it
Three read-only scans run on demand or on a cadence: security (code, secrets in git history, dependencies, infrastructure), legal exposure, and control gaps against common frameworks. Each finding can be sent to the loop, which ships the fix as a gated pull request. They are engineering reviews with stated limits: not a penetration test, not legal advice, not a certification.
Keeping control while you learn the codebase
Autonomy is a per-project setting, not a personality. Plan review makes a human approve the plan before any code is written. Manual merge means Keelen opens the pull request and you click merge. Branch-only means it pushes a branch and never opens a pull request at all. Pause one project or the whole fleet whenever you want the keyboard back.
When Keelen is not the answer
- Nobody has access to the source code at all. Recover the code first; no tool can work on a repository you cannot reach.
- You need someone to be accountable for uptime and incidents. That is a person or an agency, not a subscription.
- The app is a compiled artifact with no repository. There is nothing for a loop to work on.
Hand the work to a loop
Connect a repository, write what you want in plain language, and review the tested pull requests that come back.
FAQ
I do not know if the code is any good. How do I find out?
Run a repository-wide security scan and look at whether tests and CI exist at all. Those two facts predict most of what maintenance will cost you. Keelen's security scan is read-only and reports coverage per category, including what it could not check.
Can I keep the app running without hiring anyone?
For the recurring engineering work, often yes: dependency updates, error fixes, and small changes are exactly what an autonomous loop handles. Keep a human available for product decisions and anything irreversible.
What if I cannot review the code it writes?
Lean on the gates rather than on your own reading. Your test suite and CI decide whether a change is safe, and you can require plan approval before code is written so you are reviewing intent in plain language instead of a diff.