The Legal Checklist Before You Launch

Before you publish a website or app, assess these eight areas: an honest inventory of the personal data you collect, a privacy policy that matches that inventory, consent handled correctly for tracking, working terms of service, real data-rights controls (delete and export), accessible pages, clear pricing and cancellation if you charge money, and appropriate transparency for user-facing AI features. None of that requires a lawyer to start. Your AI builder can help implement the controls, but completion depends on the integrations, business decisions and tests. The order matters more than anything else on this page. The single most common legal failure in vibe-coded products is not a missing policy; it's a policy that contradicts the code. The AI happily writes a beautiful privacy policy mentioning services you don't use and omitting the analytics script it added three prompts ago. So: audit first, then write the policy from the audit. Never the reverse. Start with your business location, the markets you target, and what your product actually does. Foreign privacy and consumer laws can apply, but a website being accessible from a country is not by itself a universal legal trigger. For example, GDPR territorial scope includes processing in the context of an EU establishment, or a non-EU business offering goods or services to people in the EU or monitoring their behaviour there. Assess each law separately. This guide covers the layer that's near-universal, then links to the country deep-dives for the United States, the European Union and Brazil.

Key takeaways

• Assess establishment, targeted markets, processing, sector and thresholds together. A language or an incidental foreign visit is not a complete jurisdiction test.
• Audit before you draft. Ask your builder to inventory every field, cookie and third party first — a policy written from imagination is worse than no policy, because it's a documented false statement.
• Data rights must be plumbing, not prose. "You may request deletion" is not compliance if nothing in the app can actually delete an account.
• Consent is about timing: nothing non-essential should load before the user chooses. That's a code behaviour, not a banner design.
• Accessibility is now a legal requirement in the EU and a litigation magnet in the US. WCAG 2.1 AA is the working standard almost everywhere.
• The AI is a good compliance engineer and a bad compliance advisor. Use it to build the mechanisms; use a human for the judgement calls.

What decides which laws apply to you

Five questions, in order of how much they change your answer:

1. Where is the business established, and whom does it target or monitor? Mere accessibility is not enough for the GDPR targeting test. Review your marketing, customers, delivery coverage and behavioural monitoring.
2. What do you collect? A brochure site can still process IP addresses through hosting logs, embeds and analytics. Add an email field and you have a data controller's duties. Add health, biometric, precise location, financial or children's data and you jump to a much stricter tier.
3. Do you take money? Payments bring consumer-protection law: price transparency, refund and withdrawal rights, subscription and cancellation rules, tax registration.
4. Do users create content, or talk to each other? User-generated content brings moderation duties, notice-and-takedown mechanisms and liability rules.
5. Could minors use it? Not "is it for kids" — could a 12-year-old plausibly sign up. Children's rules are the strictest, the least forgiving, and the most expensive to get wrong.

Thresholds and exceptions are law-specific. Some state privacy laws use volume or revenue tests; other rules depend on the activity or type of data. Check the relevant country guide rather than treating company size as a universal exemption.

The ten things almost every product needs

1. A visible identity. Who is legally behind this? A business name, a real contact method, and in much of Europe an address and registration number. Anonymous commercial sites are non-compliant in several countries and untrustworthy in all of them.

2. A privacy policy that matches the code. What you collect, why, how long you keep it, who you share it with, what rights users have, and how to reach you.

3. Consent handled at the right moment. Analytics, pixels, chat widgets, embedded videos, custom fonts loaded from a third-party CDN — all of these can set cookies or leak IP addresses before the user has agreed to anything.

4. Terms of service. The contract: what the service does, what users may not do, payment and cancellation, liability limits, which country's courts decide disputes. Consumer-protection law overrides anything unfair you put in here, so don't over-lawyer it.

5. Working data rights. Access, correction, deletion, export, and the right to object to marketing. Build the buttons.

6. Security basics. Passwords hashed, secrets not in client-side code, admin routes actually protected, database rules that don't let user A read user B's records. Ask your builder explicitly — "vibe-coded" apps ship with permissive database rules more often than anything else on this list.

7. Accessibility. Keyboard navigation, colour contrast, form labels, alt text, sensible headings. WCAG 2.1 Level AA is the reference standard, and it's now a legal requirement for many EU-facing services.

8. Honest commerce. Total price including tax before the payment button, renewal dates stated up front, cancellation as easy as signup, and a receipt.

9. Children. If minors can plausibly reach it, you need age screening and a different data posture — usually no behavioural advertising, no profiling, and parental consent below a threshold that varies by country.

10. AI disclosure. If a user is talking to a bot, generating content, or being scored by a model, say so. Disclosure duties depend on the system, use and jurisdiction; do not imply that AI-assisted coding alone triggers them.

What your AI builder can and can't do

It's genuinely good at: inventorying its own code, listing every third-party call, building a consent banner that actually gates scripts, wiring delete/export flows, running an accessibility pass, adding disclosure text, tightening database rules, and drafting a policy from facts you give it.

It will fail you at: knowing which jurisdiction you're in, knowing your legal entity name or retention periods, judging whether "legitimate interest" applies, or telling you when you've crossed into regulated territory. It will also — and this is the dangerous one — write a confident, professional-looking policy full of invented specifics if you ask it to "add a privacy policy." That document is a public statement about your business. Treat anything it generates as a draft with placeholders, not a finished legal document.

Two things it can't do at all: sign a data processing agreement with your vendors on your behalf, and take responsibility. Classify each vendor by its actual role: processor, independent controller or sometimes joint controller. A processor needs the appropriate processing terms; a vendor is not automatically your subprocessor.

The prompt sequence (run these in order)

You can adapt these for Base44, Lovable, v0 or any chat-based builder. Run them in order — each one depends on the output of the one before.

1. Inventory what you actually have

Audit this application and produce a DATA INVENTORY as a table. For every place personal data is collected, stored, or sent, list:
1. The field name and exactly where it is collected (page, form, component).
2. Why it exists, and whether any code in the app actually reads it.
3. Where it is stored (which table or collection) and any retention logic.
4. Every third party it reaches: analytics, error tracking, email, payments, maps, fonts, embeds, AI providers. Name the service and what data it receives.
5. Whether it is sensitive data: health, biometric, precise location, financial, government ID, data about children, or race/religion/political/sexual-orientation data.

Then list separately every cookie, every localStorage/sessionStorage key, every tracking script, and every asset loaded from a third-party domain.

Report only what exists in the code. If you are unsure whether something collects personal data, list it as UNKNOWN rather than guessing. Do not write a privacy policy yet.
Copy prompt

2. Collect less

Using the data inventory above, propose a minimization pass. For each field, mark KEEP (and state the specific reason it is required), MAKE OPTIONAL, or REMOVE. Flag every field we collect but never read anywhere in the application. Do not change anything yet — give me the table and wait for my approval, then implement the approved changes one at a time.
Copy prompt

3. Draft the legal pages from the inventory

Create three pages — Privacy Policy, Terms of Service, and Cookie Policy — and link all three in the footer of every page and in the signup flow.

Rules:
- Base the Privacy Policy strictly on the data inventory you produced. Do not add categories of data we do not collect. Do not name services we do not use.
- Wherever a fact must come from me, insert a clearly marked placeholder such as [[LEGAL ENTITY NAME]], [[BUSINESS ADDRESS]], [[CONTACT EMAIL]], [[RETENTION PERIOD]], [[GOVERNING LAW]] — never invent one.
- Add a visible "Last updated" date to each page.
- Write in plain language a non-lawyer can read.

When you are done, list every placeholder you inserted, and list anything in these documents you are not confident about.
Copy prompt

4. Make consent behave correctly

Implement consent for tracking with these rules, and treat them as behaviour, not design:
- No non-essential cookie, analytics script, advertising pixel, chat widget or third-party embed loads before the user makes a choice.
- "Accept all" and "Reject all" are equally prominent on the first screen — same size, same colour weight, same position priority — plus a "Manage preferences" option with granular categories.
- Nothing is pre-selected except strictly necessary cookies.
- The choice persists across pages and sessions, and can be changed at any time from a permanent link in the footer.
- Store each choice with a timestamp and the version of the consent text shown.

Then report: which scripts are now blocked before consent, and confirm that a fresh visit fires no analytics or advertising request until a choice is made.
Copy prompt

5. Build real data rights

Add working user data controls — actual functionality, not policy text:
1. "Download my data": exports the approved scope of that user’s personal information in a machine-readable file, excluding other people’s data, secrets and privileged material. Verify identity and authorization server-side.
2. "Delete my account": deletes or irreversibly anonymizes the user's records, and before confirming, shows the user exactly what will be retained and why (for example invoices kept for tax law).
3. A way for users to correct their own profile data.
4. An internal log of each request with its date and outcome.

All three must be reachable in at most two clicks from account settings. Then tell me exactly which tables each action touches — and, importantly, what it does NOT reach: backups, logs, analytics, and any third-party service holding a copy. I need the gaps listed explicitly.
Copy prompt

6. Lock down the obvious security holes

Review this app for the security issues that create legal exposure, and report findings before fixing anything:
- Database rules: can any authenticated user read or write another user's records? Show me the rule for each table.
- Are any API keys, secrets or credentials present in client-side code or in the repository?
- Are admin routes and admin-only actions enforced on the server, or only hidden in the UI?
- Are passwords hashed, and are password reset and session expiry handled properly?
- Is any personal data written to logs or error tracking?
- Is real personal data present in seed, demo or test data?

List each finding with its severity and location. Then fix them one group at a time, starting with the database rules.
Copy prompt

7. Run an accessibility pass

Audit the entire application against WCAG 2.1 Level AA and report the findings grouped by severity, with the file or component for each. Check at minimum: colour contrast, keyboard-only navigation and visible focus states, form labels and error messages, alt text on meaningful images, heading order, link text that makes sense out of context, and behaviour at 200% zoom and on small screens. Do not fix anything yet.
Copy prompt

Then, after reading it: Fix the critical and serious accessibility issues, one group at a time, starting with keyboard navigation and form labels. After each group, tell me what changed and what is still outstanding.

8. Disclose the AI

Find every place in this app where AI generates or influences what the user sees or what happens to them: chat, recommendations, scoring or ranking, auto-replies, generated text or images, content moderation. For each one, tell me whether the user is currently told it is AI.

Then add a clear disclosure at the first point of interaction wherever it is missing, and add a section to the privacy policy stating which AI provider processes user input and what happens to that input. If you do not know whether inputs are retained or used for training by that provider, say so explicitly rather than guessing.
Copy prompt

9. Get the money flows right

Review every paid flow and make these true:
- The total price including taxes and any recurring charge, its frequency, and the next renewal date are all visible before the payment button.
- The payment button itself states that it creates a payment obligation.
- Accepting the terms requires an explicit action; nothing is pre-ticked.
- Cancellation is available from the account area in at most two clicks, with no retention offer, survey or phone call in the way.
- An email confirmation is sent containing the order details and the cancellation instructions.

List every screen you changed, and list any flow where you could not implement one of these and why.
Copy prompt

10. Pre-launch check

Run a pre-launch compliance check. Report as a checklist with PASS, FAIL or UNKNOWN for each item — answer UNKNOWN rather than guessing:
1. Privacy Policy, Terms of Service and Cookie Policy exist, are linked in the footer of every page, and contain no unfilled placeholders.
2. Business identity and a working contact method appear on the site.
3. No analytics or advertising request fires before consent, and consent can be withdrawn.
4. Account deletion and data export work end to end.
5. Every form states, at the point of collection, what the data will be used for.
6. No test or demo data, no real personal data in seed data, no secrets in client-side code.
7. Every marketing email includes an unsubscribe link and a postal contact.
8. AI features disclose that they are AI.
9. The documented children’s-scope assessment has been implemented; any age assurance is proportionate and minimizes identity data.
10. Legal pages, consent UI and error messages exist in every language the product is offered in.

For every FAIL and UNKNOWN, tell me what would fix it.
Copy prompt

How the three regions differ, in one table

Each row is a summary — the deep-dives explain the thresholds and the exemptions: United States · European Union · Brazil.

Four more markets, each with its own twist: the United Kingdom, where limited statistical analytics can qualify for a consent exception and Online Safety Act scope has exemptions; Canada, where CASL recognises express and qualifying implied consent, and Quebec adds its own privacy and language rules; Australia, where a small business may still sit outside the Privacy Act while automated-decision disclosure and children’s-code development have December 2026 milestones; and Israel, where Amendment 13 expanded privacy enforcement and spam and accessibility rules also matter.

Content rights, reviews and affiliate relationships

Keep a record of permission or licence for photos, fonts, videos and other assets. Use real testimonials with the appropriate permission and do not invent customer results, portfolio pieces or reviews. AI enhancement of your own real work can improve presentation; do not generate work or before-and-after evidence that never existed.

If a recommendation earns a commission or another benefit, disclose that relationship clearly near the recommendation. A footer policy alone may not explain a material connection at the point readers rely on it. See the FTC’s endorsement guidance.

For user uploads, separate the licence your terms request from your reporting and removal process. Do not assume that writing “users are responsible” resolves your own duties.

When to actually hire a lawyer

Do it yourself with the prompts above if you're building a brochure site, a portfolio, a booking form, a small SaaS with ordinary account data, or an internal tool. Get a professional involved — properly, before launch — if any of these are true:

• You handle health, biometric, financial or precise location data, or anything about children.
• You're building in a licensed sector: healthcare, finance, insurance, legal services, gambling, alcohol, education records.
• Your product's core function is profiling, scoring or automated decisions about people — credit, hiring, housing, insurance, education.
• You're taking investment, or your data flows are a due-diligence question.
• You're processing personal data at large scale, or acting as a marketplace between other parties.
• You've received a demand letter, a regulator's inquiry, or a data subject complaint — stop and get help immediately, don't reply from a template.

A two-hour review of a draft you already prepared is dramatically cheaper than a lawyer starting from a blank page. That's the real return on running the prompt sequence: you arrive with a data inventory and a draft, not with a question.

Maintenance: this is not a one-time task

Every time you add a feature that collects something new, add a service, or turn on a new integration, your inventory changes and your policy is now slightly wrong. The healthy rhythm: re-run prompt 1 whenever you ship something that touches data, and re-run prompt 10 before any significant release. Twice a year, re-read your own policy as a stranger and check it still describes your product.

What the build checks establish

The prompts are implementation requests, not a legal certification. Two-click controls and consent-first defaults are practical design choices, not universal statutory requirements. Confirm jurisdiction, exceptions, retention and provider contracts separately. Verify controls with test accounts and actual browser/network behaviour; a builder’s PASS based only on code inspection is incomplete evidence.

Official sources and review scope

Updated September 14, 2026. The linked sources support the scope and corrections discussed here; this is an editorial review, not an exhaustive legal opinion or a certification of your product. Check the operative rule when acting.

• EDPB lawful processing
• FTC endorsement guidance

Launch legal, not lucky. Run the ten prompts above before you connect your domain, then read the deep-dive for your biggest market: United States, European Union, United Kingdom, Canada, Australia, Brazil, Israel. And if you haven't built the thing yet, start with From Idea to Live App. You can build this.