KeelenAnswer · after the builder
I built my app with Lovable. How do I add features and fix bugs now?
Updated 11 September 2026
Export your project to GitHub first. Lovable, Bolt, v0, and Replit all connect to a GitHub repo. A repo you own is a portable handoff point. Then pick one of three paths. You can learn enough code to fix bugs and add features yourself. You can hire a developer or an agency. Or you can connect an autonomous dev loop that works the repo for you. Keelen is the third path. It records Requests and works your repo under the review and merge settings you set. Test evidence needs a verified test command for the project. Required checks must be set up in the repo.
Whichever path you pick, do one thing first. Get tests and a CI workflow in place before you add a feature. Most generated apps ship with neither. That gap 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
Most generated apps leave database rules open. They often leave secrets in client code. They also skip the checks behind the login screen. Look at those three things before you build 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. Add one test per key path (signup, payment, the one thing users came for). Then add a CI workflow that runs them on every pull request. This floor is what makes each later change safe.
Change one thing at a time, behind a pull request
Do not ask a builder to rebuild the whole app, because that is how you lose code that works. Make one pull request per change, so the diff stays small and easy to undo. That holds whether a person or a loop writes it.
Decide who does this every week
The work above never stops, so pick a plan you can keep. Use your own evenings, pay a developer, or run an autonomous loop on a monthly plan. The worst choice is no plan at all, because the app then slowly rots.
Why the second change is the one that breaks things
One pass wrote the first version of a generated app. That is why it holds together. The second change has to fit code nobody has read. There are no tests to say whether it still works. That is the real cliff. This is not a failure of the builder. It is the normal cost of software that has a past. Tests and a review gate are how a professional team deals with it.
What a loop does that a prompt does not
A loop can hold a standing roadmap and get work ready. You can set it to use independent review. You can give it a verified test command that runs on a clean checkout. It can require checks to pass. And you can add a review window before gated merge. 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.
Start with a security scan before a feature
On code you inherited, the first useful output is a map of what is wrong. Keelen's security scan reads the whole repo in an isolated VM. Its token can only read. The scan ranks what it finds. It looks at code, secrets in git history, libraries, and infra. You can send findings to the loop. The loop ships the fix as a gated pull request. This is an engineering review. It is 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 at cost. There is no markup. Compare that with an agency retainer for the same work. The math often makes the choice for you.
When Keelen is not the answer
- You want to keep prompting inside the builder's own editor. Keelen only works on a GitHub repo. It does not work inside Lovable, Bolt, or v0.
- Your app is not in version control and you do not want it to be.
- You want a person to own product decisions. Keelen runs the work and checks it. It does not decide what your product should be.
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
Can Keelen work inside Lovable or Bolt directly?
No. Keelen works on a GitHub repo, so export your project from the builder first. Every major builder supports this. Then connect that repo, and 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. Items that are large or cut across areas 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 to approve the plan before code is written, turn on plan review. You can also set the project to manual merge or branch-only. Then nothing lands without you.