Continuous compliance in Lovable. No plugin required.

Imagine someone on your team built a customer-facing tool that was not worth queuing behind the sprint. They prompted it into existence with Lovable because that was faster than filing a ticket. And it works.

But it went fast, and skipped the normal process that keeps your Privacy Policy accurate, because that process watches your main GitHub org, and this thing lives in a repository Lovable created on its own the moment the project started. Your Privacy Policy describes your main product accurately. It says nothing about what you built with Lovable.

Does Lovable have a plugin for Lawcel?

No. It's not necessary, and also not possible, there is no official Lovable plugin or extension API to build a tool into (what circulates as "Lovable extensions" are unofficial browser add-ons that sit in Chrome and touch the editor's UI, not a real integration surface into the platform itself).

But the reason we don't need a plugin to work with Lovable is because it already ships the integration surface to a Github repository, that your Lawcel account can connect to. The same is true of all vibe-coding tools that sync to GitHub, not only Lovable: the repository is the integration point.

What does Lawcel do with a Lovable-synced repository?

Lawcel is a compliance tool that watches the places your product changes and flags what that means for your legal documents. Our GitHub App installs against a repository and treats a Lovable-synced one exactly like it treats any team's: we read the diff behind each pull request and commit, classify what kind of feature and what kind of data the change touches, and flag when something needs a line added to your Privacy Policy, a clause in your Terms, or a new entry in your sub-processor list. Stripe, in the upgrade-page example above, became a sub-processor the moment it started receiving a customer's billing details, whether a person typed that integration by hand or a prompt did.

We read the code diff to classify the change. We don't check whether it is well written, secure, or correct, only what it means for what you have told your users. A commit that adds an authentication method, starts collecting a new field of personal data, or wires in a third-party API reads the same to us whether it came from a human in VS Code or a Lovable prompt that shipped in the background while someone was testing something else.

What comes back is a case in Lawcel: a plain-language summary of what changed and what it means for your documents, a risk score, and suggested text for the specific clause, linked back to the pull request that triggered it. You approve or reject each suggestion yourself; nothing publishes to your live Privacy Policy or Terms until you say so. Posting that summary as a comment directly on the GitHub pull request is a feature of paid plans; either way, the case itself always shows up in Lawcel. A prompt that only rearranges the dashboard layout opens no case at all, because nothing about it is disclosable.

How do you connect a Lovable project to Lawcel?

Two steps:

1. In Lovable, turn on GitHub sync for the project, if it is not on already.
2. If GitHub is already connected to Lawcel for your main product, widen that same installation's repo selection to include this one too, from GitHub's own installation settings. If you are new to Lawcel, sign up and connect GitHub, selecting this repository during that first setup.

It is one GitHub connection either way, watching however many repositories you point it at, not a second connection to add or pay for. From that point, every prompt that ships a real product change also ships a matching commit, and we read it. There is no separate Lovable account to authorize and nothing installed inside the Lovable editor itself, because the repository was already the connection point.

What if this Lovable build needs its own Privacy Policy?

Not every Lovable build is just a new feature of your main product. Sometimes it is a distinct tool with its own users and its own name, and your existing Privacy Policy does not cover it because we never wrote it to. When that is the case, our document generation drafts a first version instead of proposing edits to something that does not apply. The free plan includes one AI-generated document for the life of the org; drafting more than one, or redrafting later, needs a paid plan.

We ask a short set of questions about the product and how it handles data before we draft anything, because a Privacy Policy generated from nothing would just be generic text with a company name swapped in, and generic text is worse than an honest gap because it looks finished. Whether it stores payment details itself or hands them to a processor like Stripe, whether it uses analytics, and who else it sends user data to all shape what the draft actually says. Once those questions are answered, we can produce a first version of whichever document the product needs, grounded in what was actually described, not in a template written for a different kind of business. Getting the finished document live on your own site through Lawcel's hosting is also a paid-plan feature, though you can read and export whatever we draft regardless of plan.

What happens after you connect Lawcel to your Lovable project?

The next Lovable prompt that adds a feature ships its commit as usual. If that commit changes what data gets collected, who it goes to, or what a user has to agree to, we open a case describing what changed and which document it affects, with suggested text to review and approve before anything publishes. If the change does not touch anything disclosable, we open nothing, and the prompting continues.

None of this asks you to leave Lovable, slow down prompting, or learn a second tool's editor. The repository was always the connection point; the only thing that changes is that someone, or rather something, is now reading it for the one category of change a fast build cycle never leaves time for on its own. The same is true no matter how many of these things exist across the org: a partner portal here, an internal tool that grew customer-facing there, each in its own Lovable project and its own repository. We watch each the same way, once its repository is in the GitHub installation's selection, and we read each against its own set of documents rather than assume it is covered by whatever Privacy Policy happens to be linked in the main product's footer.

If someone on your team has shipped a real, data-collecting surface in Lovable outside your normal build process, I would connect the repository it is already syncing to before the next prompt adds another field to what it collects. Otherwise it keeps running as the one part of your product nothing is watching.