Skip to content

Lovable checks the app it wrote. Grace reads the whole repository.

Lovable 2.0 ships a security scan that runs before you publish, catches missing RLS policies, and can fix them for you. That is real, and it closed most of the gap this page used to be about. What it does not do is described by Lovable themselves, and it is the reason people still end up here.

What Lovable is for

  • Going from a sentence to a working app, with the schema and the frontend wired together
  • Iterating on the product while you are still finding out what it should be
  • Getting something in front of users without a team
  • Hosting, auth and a database you never had to assemble

None of this is a criticism. Lovable does it well, and Grace doesn't do it at all.

What Grace is for

  • Reading a repository whoever wrote it, generated or not, and mapping what is actually in there
  • Ranking what it finds by whether it sits on a path your users are on
  • Watching every push and pull request after launch, not only at publish
  • Turning a Sentry error in production into a pull request with the cause in it
  • Keeping the reasoning: why a trade-off was made, so the next person does not undo it

And their safety net is not nothing

Read off their own documentation in August 2026.

Worth saying plainly, because a comparison page that pretends a competitor ships no security is a comparison page nobody believes. Lovable publishes all of this themselves.

  • A basic security scan runs automatically before every publish, in ten to fifteen seconds, and covers database misconfigurations, missing RLS policies and authorization gaps.
  • Auto-fix can resolve the straightforward, low-risk findings on its own, as non-breaking changes.
  • Dependency checks run on every edit to a dependency.
  • A deep scan, described as a full AI review of the codebase, runs on demand in two to four minutes, and can be scheduled weekly or monthly on their enterprise plan.
  • Lovable holds SOC 2 Type II and ISO 27001:2022. Grace does not hold either today, and our roadmap says when we intend to.

Where it stops, in their words and ours

Lovable states the boundary of the automatic scan directly: it does not analyse your application code for logic flaws or vulnerabilities unique to how your app is built. That sentence is the whole of this page.

  • A pattern check finds the table with RLS off. It does not find the refund endpoint that trusts an order id from the request body, because nothing about that is a misconfiguration: it is your business logic, and it is wrong only if you know what the app is for.
  • The automatic pass runs at publish. The risk that matters usually arrives later, when someone adds a feature to an app that has been live for eight months and nobody remembers why a check was there.
  • The scan covers the app Lovable built. It has nothing to say about the repository you inherited from a contractor, the one your agency took over, or the half of your system that was never generated at all.
  • Findings come back as findings. Deciding which of forty matter this week, on the paths your revenue actually goes through, is still yours to do.

Where the two stop overlapping.

LovableWith Grace
Writes the first versionYes, that is the productNo, and never will
Works on a repo it did not generateBuilt around apps made in LovableThe normal case
What gets analysedThe app, for misconfigurations and known patternsThe whole repository, including logic and history
When it runsAutomatically at publish, deep scan on demandEvery push and pull request, continuously
How findings arriveA list, with auto-fix on the low-risk onesRanked by business impact, as reviewable PRs
After a production errorNot what it doesStack trace traced to the cause, corrective PR opened
Certification todaySOC 2 Type II, ISO 27001:2022None yet. Roadmap published with dates

Checked against Lovable's own documentation in August 2026. These products ship monthly. If something here is out of date, tell us and we will correct it.

Using both is the normal case.

Build it in Lovable, let their scan catch what a scan catches, and point Grace at the repository for the part that needs to know what the app is for. The two are not competing for the same minute of your day: one is how the app gets written, the other is what happens for the two years afterwards.

The five deliverables, in order →

When you don't need Grace.

The audit is free, so the worst case is an hour and a report. But there are situations where the answer is simply no, and we would rather say so here than after you have paid.

  • You are still finding the product, nothing is live, and no real user data exists yet. Ship first.
  • The app is a weekend project you would not mind rebuilding. The audit will tell you true things you have no reason to act on.
  • You have an engineering team already reviewing every change and watching production. You have what Grace sells.

What people ask about the two.

For a lot of people the honest answer is that you would not, yet. Their scan covers misconfigurations well and it is free with the product. Grace earns its place when the app has real users and real money moving through it, when the code has grown past what one scan understands, or when part of your system was never built in Lovable at all.

No. Grace does not generate applications and does not rewrite yours. It reads the repository, reports, and proposes changes as pull requests you approve one by one. If you decline every one of them, nothing about your app changes.

That is a fair question and the honest answer is on our trust page. We hold neither certification today, the audit programme starts twelve months from August 2026, and we say so publicly rather than implying otherwise. What we can offer now is narrower and checkable: read-only access to repositories you choose, revocable from your Git provider at any moment, nothing merged without your approval, and an EU hosting option.

That is the usual case. Grace starts from the repository rather than from the tool that produced it, which is precisely why agencies use it on client work they inherited.