Skip to content
ShipSecurelySecurity reference
Menu
Your tool here — sponsor ShipSecurely

Issues

Missing privacy policy and terms

If you collect accounts, emails, or payments, you need a page that says what you collect and a page that says the rules of the product. This is not legal advice.

Share link · Share on X

Last updated

mediumPrivacy

Shows up in: Next.js, Supabase, Vercel, Stripe

Markdown version

What it is

This page is not legal advice, and publishing a policy does not make you compliant with anything by itself. Laws differ. GDPR and CCPA are examples of laws that can apply depending on where you operate and who your users are. Find out whether they apply. Hire a lawyer before you promise a regulator anything.

What is still true in plain terms: if people give you an email, create an account, pay you, or show up in your analytics, you should say so in public before you ask for the data.

A privacy note that is specific is better than a generic template you copied. Name the companies that actually process data for you. If you use Supabase, Stripe, Vercel, and a product analytics tool, those names belong on the page, along with what each one receives. If you do not use one of them, do not list it because a boilerplate did.

Terms are the rules of the product: what people may do with it, how billing works if you charge, and that you can close an account that abuses it. A lawyer should review them if money or other people's data is involved. Do not copy another company's terms. Their business is not yours.

If you do not use non-essential cookies or third-party analytics, you do not need a cookie banner to look grown-up. Add one when you actually set those cookies.

How to check in 5 minutes

  1. Open /privacy and /terms on the deployed site. A 404 on either, while you have a signup form, is the gap.

  2. Read the privacy page and highlight every company name. Compare the list to the env vars and scripts in the app. A missing processor, or a processor you do not use, means the page is fiction.

  3. Find the account delete path. The privacy page should say how someone asks for deletion, and the product should have a way to do it that is not "email a dead inbox."

  4. If you take payments, confirm the terms mention billing, and that Stripe's hosted fields are what you use if you do not want card numbers on your server. Do not invent a PCI claim.

How to fix

Next.js

Add two routes, /privacy and /terms, linked from the footer on every page including signup. Write them from the data you actually collect. Include:

  • What you collect (account email, files, payment status, logs).
  • Why.
  • Who else processes it, by name.
  • How long you keep it, in words a person can check.
  • How to contact you and how to delete an account.

Use a real contact address. A placeholder like the one on this reference site is honest only while the site is a draft. Do not ship a customer app with an address that does not reach you.

Supabase

If Auth stores emails and Postgres stores user rows, say that Supabase is the processor for that data. A delete account action should delete the Auth user and the rows, or document what you retain and why. RLS does not write the policy page for you.

Vercel

Hosting logs can include IP addresses. If you deploy there, say that the host logs requests. Check Vercel's current data processing terms rather than guessing their retention.

Stripe

If Stripe processes payments, say so, and link Stripe's own privacy notice rather than restating it badly. Do not claim you never see card data if your integration is not Stripe's hosted form. Read your integration.

Copy-paste prompt

Paste this into Cursor, Claude Code, or whichever agent is editing the repo. Read the diff before you merge it.

You are adding a privacy page and a terms page based on this repository. This is not legal advice. Do not copy another company's policy.

1. Search the code for analytics scripts, auth, payment, email, and storage providers. List only the ones this repo actually uses.
2. Add /privacy describing what is collected, why, those providers, how to contact the operator, and how to delete an account. Where the code has no delete path, say so in your summary instead of inventing one.
3. Add /terms with acceptable use and, if payments exist, a plain description of billing. Leave a TODO that a lawyer must review it before launch.
4. Link both from the footer.
5. Do not add a cookie banner unless you find non-essential cookies or analytics.

Use plain language. Do not claim certifications the repo does not show.

Questions

We are pre-launch and only have test users. Does this apply?

If the test users are other people and you are collecting their emails, tell them what you collect. "Pre-launch" is not a category that erases that.

Can I use a generator and ship it?

You can use a generator as a draft. You still have to delete the clauses that do not match the app and add the processors that do. A page that names the wrong company is worse than a short honest one.

Sources

Related