Your Lovable app needs a privacy policy at the first sign-up.

You built it yourself. You described what you wanted, Lovable built it, and after a few evenings it runs at a URL strangers can reach. People can sign in with their Google account. A form takes an email address. Maybe there is already a payment button, because charging for it was the point.

The product works. What does not exist yet is anything describing it. No Privacy Policy, no Terms, possibly no company either. That gap is easy to leave open, because it feels like something you do once the product is real. But your app started making promises the first time a stranger typed their email into it. Your sign-in provider requires those promises to be published before you go public, and your payment provider puts them on its checklist for your site.

What does your app owe its users on day one?

The rules here are the GDPR's, which apply once you take sign-ups from people in the EU, wherever you are yourself 1. Three things are already true of your app:

The duty to tell people what you collect falls on you, from the first sign-up. GDPR Article 13 puts it on whoever decides what the app collects and why. On a product you built alone that is you personally until there is a company to hold it, and a policy can name you as a person. Article 13(1) says the information has to reach the user "at the time when personal data are obtained" 1: who you are, what you use the data for and why you are allowed to, who else receives it, how long you keep it, and what the user can ask of you. The twelve things a Privacy Policy has to get right before launch walks through the full list.

Signing in with Google requires a published policy. If your app offers Google sign-in, Google's API Services User Data Policy requires you to publish a privacy policy documenting how the app handles user data, and to list its URL on the OAuth consent screen in the Google Cloud console once the app is available to the public. Google says it may revoke or suspend your API access if you fall out of line with that policy. If that access goes, nobody can sign in to your product. Verification is a separate step that Google does not require until the app has 100 users, though people signing in click through an "unverified app" warning until you do it. When you verify, Google's requirements also say where the policy should live: on the same domain as your homepage, linked from it, with the consent-screen link pointing at the same document.

Taking payments comes with a website checklist. Stripe's website checklist lists what it expects the website behind your account to carry, and a privacy policy is on it, alongside a clear description of what you sell, a way to contact you, and your refund and cancellation terms. On several of those items Stripe says it may review your site and ask you to add what is missing.

None of these wait for traction. They land on the version of the product you have now, built by one person over a few evenings.

What if you have no Privacy Policy at all?

Then that is where we start, and for a Lovable build it is the ordinary case rather than an edge case.

Lawcel is a compliance tool: it watches the places your product changes and tells you what those changes mean for your legal documents. When you sign up, we crawl your site to see what is already published. If the answer is nothing, we draft a first document from scratch.

Before drafting we build a record of the product, from what the crawl found and from questions we ask you: who stands behind the product, what it collects, who else receives that data, whether you take payment and how, whether you run analytics. Expect to answer properly rather than click through. A Privacy Policy generated from nothing is generic text with a company name swapped in. It makes claims about your product that are false the day you publish it, and Google holds you to those claims: its policy limits what you may do with sign-in data to what your published policy discloses. Answer the questions, and what comes out is grounded in your product rather than in a template written for a different business.

My own advice on order: do not try to write the policy first and build to it. Describe what the app already does today, publish that, and then keep it true as you keep prompting. A policy written ahead of the product is a guess, and it is the guess Google and Stripe will read.

How do you connect a Lovable project to Lawcel?

There is no Lovable plugin for Lawcel, and none is needed. Lovable does take custom MCP servers as chat connectors on every plan, but a connector only answers when you ask it something, and monitoring has to see every change. Every change lands in the repository, so the connection is three steps, none of them inside Lovable's editor (we have made the same argument for products that deploy through Vercel):

1. In Lovable, turn on GitHub sync for the project if it is not on already. Lovable creates a repository, private by default, keeps it in step with your project in both directions, and its changes land there as commits. The sync is available on all plans. Leave it on the branch Lovable created, usually main; you have not changed this unless you went looking.
2. Sign up for Lawcel and connect GitHub, selecting that repository during setup.
3. In Lawcel, open Settings, then Ingestion, and turn on Analyze direct pushes. It is off by default, because most repositories reach their main branch through pull requests, which we already read. Lovable's sync pushes straight to the branch by default rather than opening a pull request, and this setting is what makes us read those pushes.

Only pushes made after you turn the setting on are analysed, so do it before the next prompt rather than after.

What happens after you connect?

You keep prompting. The next change that adds a feature lands in the repository as a push, and we read the diff behind it to work out what kind of feature and what kind of data it touches. We are not reviewing the code: not whether it is well written, secure, or correct, only whether it changes what you have told your users. A commit that adds a login method, starts collecting a new field, or wires in a third-party API reads the same to us whether a person typed it in an editor or a prompt produced it while you were testing something else.

When something is disclosable, meaning your users have to be told about it, you get a case: a plain-language summary of what changed, which document it affects, a risk score, and suggested text for the specific clause, linked back to the commit that triggered it. You approve or reject it yourself, and nothing reaches your published Privacy Policy or Terms until you say so. A prompt that only rearranges the dashboard opens no case at all, because nothing about it has to be told to anyone.

Adding a payment button is the clearest example. The moment it starts sending a customer's billing details to a payment processor, that processor has become a recipient of your users' personal data, and recipients, or at least the categories they fall into, are one of the things Article 13 says the policy has to disclose 1. Naming Stripe is the plain way to do that. Nobody types that sentence into their policy the same evening they add the button.

If you have shipped something in Lovable that real people can sign up for, I would connect the repository it is already syncing to, turn on direct pushes, and do it before the next prompt adds another field to what it collects. You built the product on your own. This is the part you do not have to.