KeelenAnswer · inherited codebase
My developer left and I cannot code. How do I keep my app going?
Updated 11 September 2026
Secure access comes first. Make sure you own the GitHub organisation, the hosting account, the domain, and the app store listings. Rotate every credential the person who left still holds. Next, make the app buildable by someone other than them. Write a setup guide. Get a working CI pipeline. Add a test that proves the app boots. Only then pick who does the ongoing work: a new hire, an agency, a freelancer, or an autonomous dev loop such as Keelen. Keelen works Requests under the review and merge controls you set on the repository.
Do not start with features. An app nobody can build is a crisis. So is an app nobody can deploy. It stays that way until the pipeline works without the person who left.
Watch this answer on YouTube (My developer left and I cannot code. How do I keep my app going?) →
What to do, in order
Take ownership of every account
Start with the accounts. You need the GitHub organisation, the hosting, the domain registrar, the database, the error tracker, the app store listings, and the payment processor. Move each one to an account you control. Rotate the keys. Revoke the access the person who left still holds.
Prove the app can be built and deployed by someone else
Deploying may depend on a laptop that nobody has any more. Fix that first. Set up a CI workflow that builds, tests, and deploys from a clean checkout. That turns knowledge held in one head into something you can hand over.
Get a smoke test in place
Add one test that proves the app starts and the main path works. Treat its result as evidence about that path. Read the change too, and check that it does what it is meant to do.
Commission a review of what you inherited
Read it all: the code, the secrets in git history, the dependencies, and the setup. That shows what you own. Expect surprises in the secrets and the dependencies.
Choose the ongoing arrangement deliberately
Pick a hire, an agency, a freelancer, or an autonomous loop. Weigh speed against who is responsible. Write down who decides what. Then 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. So do not start with a feature. Build a CI workflow and a setup guide first. They make every later option possible, whether that is a hire, an agency, or a loop.
What a loop can pick up
Keelen connects to the repository. It finds the stack and the test command. Then it works from written requests. That suits the work an unfamiliar codebase creates. It can add tests, patch dependencies, fix reported errors, and make small changes one reviewable pull request at a time. A separate adversarial reviewer reads the diff. It does not see the conversation that wrote the code. The review model comes from your project settings. Red first proof and clean checkout tests need a verified project test command. Gated auto-merge needs the repository checks and a review window you set up. Plan review, manual merge, and branch-only mode each pick where a person must decide. Check the real evidence before you accept the result.
Know what you inherited before you change it
Three scans are read only. You run them on demand. Your own agent or scheduler can repeat them. The security scan covers the code, the secrets in git history, the dependencies, and the infrastructure. The legal scan maps code to common duties. The controls scan looks for gaps against common frameworks. Any finding in the code can become a Request. The normal planning, development, and review process then takes over. Check the evidence. Check whether the finding was resolved. These are engineering reviews with limits. They are not a penetration test. They are not legal advice. They are not a certification.
Keeping control while you learn the codebase
Autonomy is a setting you pick for each project. 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 own uptime and incidents. Only a person or an agency can do that. A subscription cannot.
- 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 and write what you want in plain language. 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 security scan of the whole codebase. See whether tests and CI exist at all. Use what you find to scope a real technical review. Keelen's security scan is read only. It reports coverage per category, and it also reports what it could not check.
Can I keep the app running without hiring anyone?
For the recurring work, often yes. An autonomous loop handles updates, error fixes, and small changes. Keep a human around for product decisions. Keep one for anything you cannot undo.
What if I cannot review the code it writes?
Lean on the gates instead of on your own reading. Your test suite and CI report the checks they run. They do not decide whether a change is safe or acceptable. You can require plan approval before any code is written. You can also get a qualified technical review when you need one.