Lovable is fantastic.

It lets you build a full application in minutes. Front-end, back-end, database, workflows, everything.

Business teams love it.

Engineers, however, tend to have a slightly different reaction when they hear:

“Good news, I built it in Lovable.”

Because somewhere deep inside their brain, a small voice whispers:

“We have just created more technical debt.”

Lovable doesn't know your architecture.

It doesn't know your domain constraints.

And it definitely doesn't know which parts of your system took three years to get right.

Which means if you're not careful, Lovable doesn't just generate software.

It generates parallel engineering. A completely separate system that nobody planned and nobody owns.

And what's worse: engineers can’t even help.

Because Lovable can undo their changes or bypass their systems in seconds.

I ran into exactly this problem

While working as CTO in residence for a client, I watched this scenario unfold in real time.

The company processes geological datasets from around the world. Surveys, drilling results, satellite data. All of it eventually needs to be standardised into the same internal model.

This work was mostly done by students manually processing datasets.

Then one day the lead geologist showed up with an announcement.

They had built an internal tool in Lovable.

And to be fair, it worked.

The students now had a guided interface that walked them through the workflow. Upload the dataset, process the data, annotate the location on a map, export the standardised result.

The process became clearer. Errors dropped. Productivity went up.

But Lovable had also quietly done something else.

It had recreated parts of our engineering stack.

The AI had implemented parts of the transformation logic inside Supabase functions, completely unaware that the engineering team already had ETL pipelines handling those tasks.

Those pipelines weren't trivial.

The team had spent significant time optimising prompts, benchmarking model quality, and building the processing stack around tools like GDAL. Something Lovable can't install, but is essential when working with geospatial data.

Lovable happily recreated simplified versions of that logic inside Supabase.

Which meant it was quietly bypassing the very systems that gave the company its edge.

The front-end Lovable generated was business-accelerating.

The data processing back-end logic… considerably less so.

Not maliciously.

Just… enthusiastically.

And that’s when the real problem appeared.

Because if a business user can generate application logic with a prompt, they can also accidentally bypass the systems that ensure quality, consistency, and reliability.

Which means the question isn't:

“Is Lovable useful?”

It absolutely is.

The real question is:

How do you let people move this fast without breaking your architecture?

So I built something to solve it

Instead of banning Lovable (believe me, that was my first instinct), we wrapped it in guardrails.

The result is a small project called madewithlovable: a reference implementation of how to safely run Lovable inside a real engineering workflow.

You can explore it here:

Interactive walkthrough

https://d12vini1os6dc2.cloudfront.net/

Full codebase
https://github.com/madewithlove/madewithlovable

Ironically, the walkthrough explaining how to safely use Lovable… was itself built in Lovable.

Because the tool isn't the problem.

The absence of guardrails is.

Step one: escape the platform

The first thing we did was connect Lovable to GitHub.

This might sound obvious, but without it the entire project effectively lives inside Lovable’s platform. No version control. No external backup. No code ownership. No way to involve engineers. Pure vendor lock-in.

Exporting the project into Git immediately brings it into the normal engineering universe. The code stops being an artifact inside a tool and becomes part of the system.

Step two: teach the AI its boundaries

Next came the most important piece: guardrails.

We introduced a file called LOVABLE.md in the repository.

It defines the rules for what Lovable is allowed to modify and what it must leave alone.

Infrastructure files? Off limits.
CI/CD pipelines? Off limits.
The engineering-maintained API client? Absolutely off limits.

Lovable can modify application code, but the architecture remains protected.

Think of it as letting the AI redecorate the house, but not move the load-bearing walls.

There is one important detail here though.

Creating LOVABLE.md alone does nothing.

The file exists so the rules live inside the repository, versioned in Git where engineers can review and enforce them.

To make Lovable actually respect those rules, we add an instruction in Lovable's Knowledge settings:

Adhere to all guidelines detailed in LOVABLE.md in the root directory.
You are not allowed to change LOVABLE.md.

The AI is explicitly told to treat that file as its rulebook.

And because the rulebook lives in Git, we can automate checks against it during pull requests. If Lovable-generated changes violate the guidelines, the CI pipeline catches them.

This turns the file into something more useful than documentation.

It becomes a contract between engineering and the AI.

Step three: give engineers real tools again

Lovable’s editor is great for quick iteration.

But engineers tend to prefer slightly more powerful tools than a browser text area.

So we added a Docker-based local development environment. Engineers can clone the project, run docker-compose up, and suddenly the application runs locally.

That means:

  • proper IDEs
  • debugging tools
  • real development workflows
  • and AI coding agents like Cursor or Claude Code

Lovable becomes just one interface among many, not the entire development environment.

Step four: own your production environment

The next step was decoupling the app from Lovable’s hosting.

Instead of deploying through the platform, the front-end can be built normally and hosted on infrastructure we control, for example AWS S3 + CloudFront.

Now the deployment pipeline belongs to the company, not the tool.

And if Lovable disappears tomorrow, the application keeps running.

Which tends to be an underrated feature in production systems.

Step five: automate the boring safety checks

Finally we wired everything into CI/CD.

Because no matter how many guardrails you define, you should assume one thing:

Eventually the AI will find a way around them.

So the pipeline acts as the final libero protecting the production branch.

Every change runs through automated checks. Builds execute, and PRs are validated against the rules defined in LOVABLE.md. If Lovable touches infrastructure, CI/CD, or the engineering-maintained API client, the pipeline blocks the change.

Releases also follow a controlled path.

Business users get a simple button to promote main to production, but the process actually goes through Claude. Claude opens the PR, summarises the changes, and triggers the deployment workflow.

This exists for a very practical reason: GitHub Actions triggered by GITHUB_TOKEN can't trigger new workflow runs. So a PR created by the GitHub bot wouldn’t run the deployment pipeline.

Claude solves that.

When the PR is created, Claude also reviews the changes against the guardrails in LOVABLE.md.

We now have vibe coding reviewed by vibe coding.

Automation becomes the responsible adult in the room.

The Lovable paradox

Lovable is incredible at building applications quickly.

But speed without strategy is just chaos with a progress bar.

Once the guardrails were in place, the dynamic changed completely.

The geologists could continue improving their workflow. Engineers retained control over architecture and production systems. Everyone moved faster without accidentally rewriting core infrastructure.

Lovable didn’t replace engineering.

It just made experimentation dramatically cheaper.

And that turns out to be a very powerful combination.

Because the real lesson isn’t that AI tools are dangerous.

It’s that speed without architecture always is.

Follow our bi-weekly SaaS show

Fast, honest insights from the trenches of SaaS. Andreas and Sjimi, partners at madewithlove, share what they’re seeing inside real SaaS teams and products every two weeks.