I spent some of my summer building a real product on one of the popular AI app builders in the market, lovable.app. Not a weekend toy — a full web app with authentication, a database-backed data model, a genuinely interactive UI, and several third-party API integrations wired-in.
I'm a cloud architect by day. I am used to design a VPC topology or doing some Site reliability but frontend development was never my strength. Platforms like Lovable filled exactly that gap: I was able to go from idea to a working, demoable app in few days, without writing much frontend code by hand myself.
That speed created a new problem fast. The moment the app was good enough to show other people, "just keep prompting the same project" stopped being an acceptable way to ship. I needed a dev environment I could break freely, a production environment I couldn't, and a controlled, reviewable path between the two. Here's what I ended up with, and why some approaches didn't get me there.
Why branching in a single repository falls short
Lovable has Github integration and Lovable's GitHub integration is a genuine two-way sync: every AI-driven change in the editor shows up as a commit on GitHub, and commits pushed to GitHub sync back into Lovable. But that sync is scoped to one branch per project, normally main. Also there are some lovable specific files which are tightly bound to the project in the github repository. There's a Labs feature that lets you create and switch branches from inside the editor, but it doesn't give you two environments running side by side — it gives you one editor context that you manually flip between, with a manual GitHub merge whenever you want to promote.
For me, the bigger issue sits one layer down. Controlled deployments, isolating Lovable's secrets manager and also isolating the connected backend (Supabase, in my case) which are scoped to the project, not to the git branch. A "dev" branch and a "prod" branch in the same Lovable project still point at the same database and the same secrets. That's not a controlled deployment story and we cannot go to production with this setup.
What worked: two Lovable projects, two GitHub repos
Instead, I ran two entirely separate Lovable projects, each wired to its own GitHub repo:
Each project has its own backend, its own secrets, its own deploy target. Nothing in dev — schema experiments, half-finished features, throwaway API keys — can reach production, because there is no shared infrastructure for it to reach. That's the isolation branching couldn't give me.
The per-feature lifecycle: two review gates, one scripted promotion
The environment split solved isolation. It didn't by itself solve control — I still needed a repeatable, reviewable way to move a feature from dev to prod. What I settled into, per feature, looks like this:
The detail that matters most here: promotion is a pull, not a push. The prod repo reaches out and pulls dev's work in, and the PR is opened inside the prod repo, comparing the pulled branch against prod's own main. That keeps the review and merge decision on the production side, where it belongs, and it means prod's Lovable project — which only reacts to its own main — cannot change until that PR is actually merged there. Nothing dev does can push its way into production; production has to choose to pull it in.
Because the prod side is now a completely ordinary GitHub repo, it gets all the standard governance for free: required reviewers, branch protection on main, required status checks. A GitHub Actions workflow runs the automated test suite against every promotion PR before a human ever looks at it — by the time someone clicks "merge," the code has already passed a design review, an implementation review in dev, a full dev-environment test pass, and an automated test suite on the promotion PR itself. This way, we have a pipeline that behave like a properly gated SDLC instead.
Secrets handling
I used Lovable's built-in Secrets manager rather than an external vault, and the project-per-environment split turned out to make that safer, not riskier.
Lovable's Secrets feature stores values like API keys and tokens encrypted, and injects them server-side into Edge Functions — they never reach the browser.
Because dev and prod are separate Lovable projects, their secrets are naturally partitioned — there's no shared secret store for a dev-side mistake to expose, and no risk of a dev experiment accidentally reading (or logging) a production credential.
Trade-offs, honestly
This setup isn't free:
- Duplication risk. Schema and structural changes have to travel through the promotion pipeline deliberately. If someone edits the prod project directly instead of promoting from dev, the two repos drift and there needs to be mechanisms to port those changes back to dev. Also, two Lovable projects and two Supabase projects means twice the account and cost overhead
- Less control over the code. Implementation details — library choices, code shape, how a function is structured — come from the model's judgment, not yours, unless you explicitly push back in the prompt.
- The pipeline has to be built. None of this — the promotion script, the CI checks, the branch protection — comes out of the box. It's regular GitHub/DevOps tooling layered on top of Lovable, not a built-in feature.
- Some issues only show up in prod. Some occasional security vulnerabilities appear only in prod the fix needs to go outside the normal promotion flow, this needs to be back-ported into the dev repo afterwards. That's a deliberate, occasional exception, not the default path — but it's a real gap the process has to account for.
Takeaways
If you're evaluating Lovable or a similar vibe-coding platform tools for anything beyond a prototype, the single most useful mental shift is to stop treating it as "one project, one place things live" and start treating each project as just another deployable unit in a normal software pipeline.
Also, tools like this are providing the ability to build a real, working app into the hands of far more people than they could do this even a year or two ago. I got here with weak frontend skills, and I still shipped a working full-stack product. The same is true for people with no engineering background and this is genuinely opening the door for non-technical builders to turn an idea into a working product themselves.
Sources:
Top comments (0)