KeelenAnswer — after the builder
I built my app with Lovable. How do I add features and fix bugs now?
Updated 20 August 2026
Export your project to GitHub first. Lovable, Bolt, v0, and Replit all hand you a real repository, and the repository is what every serious tool works on from here. Then pick one of three paths: learn enough code to maintain it yourself, hire a developer or agency, or connect an autonomous dev loop that works the repository for you. Keelen is the third path: it plans, writes, tests, and merges changes on your own repository continuously, and it gates every change on tests and CI so unattended does not mean unreviewed.
Whichever path you pick, do one thing before adding any feature: get tests and a CI workflow in place. Generated apps usually ship without either, and that absence is why the second change breaks the first.
What to do, in order
Export to GitHub and take ownership of the repository
Every builder has a GitHub export. Use it. Once the code is in a repository you own, you are no longer locked to one vendor's editor, and you can point any tool, human or otherwise, at it.
Read what you actually shipped
Generated apps commonly leave database rules permissive, secrets in client code, and no authorization checks behind the login screen. Review those three things before you add features on top of them.
Add a test suite and a CI workflow
You do not need full coverage. You need a smoke test that proves the app boots, a test per critical path (signup, payment, the one thing users came for), and a CI workflow that runs them on every pull request. This is the floor that makes every later change safe.
Change one thing at a time, behind a pull request
Prompting a builder to regenerate a whole app is what loses working code. A pull request per change keeps the diff readable and reversible, whether a person or a loop writes it.
Decide who does this every week
The work above is not a one-off. Pick the sustainable option: your own evenings, a paid developer, or an autonomous loop on a monthly plan. The failure mode is picking none and letting the app rot.
Why the second change is the one that breaks things
The first version of a generated app is coherent because one pass wrote all of it. The second change has to fit code nobody has read, with no tests to say whether it still works. That is the real cliff, and it is not a failure of the builder: it is the normal cost of software that has started to have a past. Tests and a review gate are how every professional team handles it.
What a loop does that a prompt does not
A builder responds to the prompt in front of it. A loop holds a standing roadmap: it picks the next task itself, implements it, proves the new tests fail before the fix, has an independent reviewer read the diff, runs your suite on a clean checkout, and waits for CI before anything merges. 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.
Start with a security scan, not a feature
On an inherited codebase the first useful output is a map of what is wrong. Keelen's security scan reads the whole repository in an isolated VM with a read-only token and ranks what it finds across code, secrets in git history, dependencies, and infrastructure. Findings can be sent to the loop, which ships the fix as a gated pull request. It is an engineering review, not a penetration test.
What it costs to keep going
The Indie plan is $29 a month for 200 iterations across 3 projects. You bring your own model key, so tokens bill to your provider account at cost with no markup. Compare that against an agency retainer for the same maintenance work and the arithmetic is usually the whole decision.
When Keelen is not the answer
- You want to keep prompting inside the builder's own editor. Keelen works on a GitHub repository, not inside Lovable, Bolt, or v0.
- Your app is not in version control and you do not want it to be.
- You want someone to take accountability for product decisions. Keelen executes and verifies; it does not decide what your product should be.
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
Can Keelen work inside Lovable or Bolt directly?
No. Keelen works on a GitHub repository. Export your project from the builder first (every major builder supports this), then connect that repository. From then on the builder is optional.
My app has no tests at all. Is that a problem?
It is the normal starting point for a generated app, and it is the first thing to fix. Ask for a smoke test and a CI workflow as your first request. Keelen's own merge gates need a suite to run, so building that floor is work it does early rather than skips.
Will it rewrite my whole app?
No. Work arrives as one task per pull request, scoped to the request you wrote. Large or cross-cutting items are refused at planning time and sent back for splitting rather than attempted as one sweeping change.
What if it makes a change I do not want?
Close the pull request. If you want approval before code is written at all, turn on plan review, or set the project to manual merge or branch-only so nothing lands without you.