To write a privacy policy for a side project, start with what your project actually does with data, not with a template. Spend one evening listing every form field, cookie, log, analytics tool, email provider, payment processor, host, error tracker and AI API that touches user data. Then write short plain sections from that list: what you collect, why, who you share it with, how long you keep it, how people can ask to see or delete it, and how to reach you. Date it, link it from your footer and signup, and update it every time you add a new tool.
This is for people with a day job who ship a small app, browser extension or SaaS on the side and suddenly need a privacy policy because a store, a payment provider, a login provider or a law asks for one. It is a practical guide, not legal advice. Store and regulator pages linked here were checked on 2 November 2026 and change often. The worked example near the end is made up.
Do I need a privacy policy for a side project?
If real people use it, almost certainly yes, and the first to tell you is usually a store or a vendor, not a lawyer:
Google Play. The Play User Data policy says all apps must link a privacy policy in Play Console and inside the app, even apps that access no personal and sensitive user data. It must be a public web page, not a PDF.
The App Store. Apple's App Review Guidelines (section 5.1.1) require a privacy policy link in App Store Connect and inside the app, covering what data you collect, how, every use, retention and deletion, and how users can request deletion.
The Chrome Web Store. Its privacy policy rule says that if your extension handles any user data, you must post an accurate and up to date policy covering how you collect, use and share it, and with whom. The SideHunt guide to shipping a browser extension as a side project covers the rest of the listing.
Sign in with Google. Google's OAuth app verification requirements say the policy must be hosted on your homepage's domain, linked from that homepage, match the link on your OAuth consent screen, and explain how you access, use, store or share Google user data.
Your payment provider. Stripe's Data Processing Agreement says the business must give customers the necessary notices, "including by making available a Privacy Policy".
The law. California's CalOPPA covers commercial sites and online services that collect personally identifiable information from California residents, and the California Attorney General's CalOPPA announcement says that means any operator in the world. If you have EU users, the GDPR sets a list of things you must tell people when you collect their data.
None of these care whether you charge money.
How do you build a data inventory in one evening?
A data inventory is a plain list of every piece of personal data your project touches: where it comes from, why you have it, which service holds it and how long it stays. It is most of the job. Once it exists, the policy almost writes itself, and it stays honest.
Walk the product as a new user. Sign up, use the main feature, pay if you can, delete your account if that exists. Note every field and every email you receive.
Search your code for the quiet stuff. Script tags, SDK imports, API keys in your environment file, anything that calls another company.
Open every vendor dashboard. Host, database, email, analytics, error tracking, payments, support inbox, AI provider.
Check your logs. Your host probably keeps request logs with IP addresses. Find the retention period in its docs.
Fill in one row per item. If you cannot answer "why do I have this?", stop collecting it.
Data | Where it comes from | Why you have it | Who holds it | How long you keep it |
|---|---|---|---|---|
Email address | Signup form | Login and account emails | Database host, email sending service | Until the account is deleted |
Payment details | Checkout | Taking payment | Payment processor (you never see the card) | Set by the processor; invoices as long as tax rules need |
Page views | Analytics script | Knowing which pages get used | Analytics tool | The tool's retention setting |
Error reports | Error tracking SDK | Fixing crashes | Error tracker | The tracker's retention setting |
Text sent to the AI feature | The main feature | Producing the result asked for | AI API provider | What the provider's data use page says |
Request logs with IP address | Every visit | Security and debugging | Host | The host's log retention |
That is an example layout; every row in yours should be something you can check today.
Why are third-party services part of your privacy policy?
Because most of a side project's data never sits on a machine you own. It sits with your host, database, email service, analytics tool and AI provider. These are often called subprocessors: services that process personal data on your behalf. Every gatekeeper above asks about them. Chrome wants all parties you share data with. Apple wants third parties such as analytics tools and SDKs to protect data the way your policy promises. CalOPPA asks for the categories of third parties you may share information with.
So the "who holds it" column becomes a short subprocessors list in your policy. For a side project, name each service with one line on what it does for you: hosting and database, login emails, payments, analytics, crash reports, AI responses. Card details go to the payment processor, not to you, so say that too.
The AI line deserves care. If you send user text to a model API, say so plainly and describe what the provider does with it using the provider's current terms, not a guess.
What sections does a privacy policy for a side project need?
Fewer than a template suggests, in plain words. The European Commission's list of what information you must give people whose data you process reads like a table of contents: who you are, why you use the data, which data, the legal justification, how long you keep it, who else receives it, whether it leaves the EU, people's rights, the right to complain to a data protection authority, the right to withdraw consent, and any automated decision-making. It asks for clear and plain language. For a small product, that becomes:
Who runs this. Your name or company, the product name and a contact email. Google Play also wants the developer or app named in the policy.
What you collect. Grouped from the inventory: account data, usage data, payment data, things users create.
Why, and on what basis. One reason per group. For EU users, name the legal basis, such as providing the service they signed up for.
Who you share it with. The subprocessors list, plus whether you sell data or use it for ads.
How long you keep it. The last column of the inventory.
Rights and how to ask. How to get a copy, correct or delete data, and where to write.
Changes. How you announce changes, and the date this version took effect.
Example wording only, not legal advice, and only useful if it is true for you:
Example: "When you sign up we store your email address so you can log in and receive account emails such as login links and receipts. We send these through our email provider, listed below. We keep your email address until you delete your account."
Example: "We do not sell your data or use it for advertising. To get a copy of your data or have it deleted, email us from the address you signed up with."
If a sentence would be just as true of any website on earth, it is probably filler.
Can a privacy policy generator or template do the job?
A privacy policy template or generator is useful as a structure and a reminder of topics you forgot. The trap is accepting its defaults. Generators cover many businesses at once, so they happily describe advertising partners, location tracking and data sales your project has never done. Then your policy is inaccurate, which is exactly what the gatekeepers object to: Chrome asks for an accurate policy, and the Play policy tells you not to give misleading or inaccurate information about your data practices.
Start from a generator if it helps, then go line by line against your inventory and rewrite everything that is not true:
Template line | Honest line for a small project |
|---|---|
"We may collect information from a variety of sources." | "We collect the email you enter at signup and the projects you create." |
"We may share your information with our partners." | "We share data only with the services listed below, which run the product for us." |
"We retain data for as long as necessary." | "We keep account data until you delete your account, then remove it within 30 days." |
"We use industry-standard security measures." | "Data is sent over HTTPS and stored with our database host. Only I have admin access." |
"We use cookies to improve your experience." | "We use one cookie to keep you logged in and no advertising cookies." |
The 30 days is an example. Write the number you actually follow.
What about cookies and consent banners?
Keep this part short and true: which cookies or similar storage you use and why, such as a login session cookie. If you add tools that set non-essential cookies and you have EU or UK users, consent rules may apply, which is a separate decision from the policy. Many side projects sidestep most of it with cookieless analytics; the SideHunt guide to setting up analytics you'll actually check walks through that choice.
How do you handle a request to see or delete data?
You do not need a portal. You need one email address you actually read, a simple log and a deadline. The European Commission's guide for individuals says organisations must respond without undue delay and at the latest within one month. The EDPB's guide for small businesses adds that complex requests can be extended by two further months if you tell the person within the first month, that you may ask for more information if you reasonably doubt who is asking, and that you should keep track of requests and answers.
One address, named in the policy and forwarded to your phone.
A log: date received, who, what they asked, what you did, date answered. A spreadsheet is enough.
A light identity check: reply to the email address on the account.
The inventory as your checklist: every row, including vendors, is a place to look.
Where should the privacy policy live, and how do you date it?
On its own page on your main domain, at a plain address like /privacy, as normal web text. Then link that one URL everywhere:
The footer of every page, labelled Privacy. CalOPPA counts a homepage text link containing the word "privacy" as one way to post it conspicuously.
Signup and checkout, next to the button.
Store and login fields: Play Console, App Store Connect, the Chrome Web Store dashboard and the OAuth consent screen all take a URL. Use the same one.
Inside mobile apps, usually in settings or about.
Put "Last updated" and the date at the top. CalOPPA asks for an effective date and a description of how you tell people about material changes; for a side project, updating the date and emailing active users about big changes is a reasonable approach.
Terms of service are a separate document. The Aura++ guide to writing terms of service for your SaaS as a solo founder is the companion to this one.
How do you keep a privacy policy accurate when you add a tool?
A policy goes stale the day you add a chat widget, an analytics script or an AI feature without touching it. Add one line to whatever checklist you use before shipping a new tool or SDK:
"Does this touch user data? If yes, add a row to the data inventory, update the privacy policy and its date, and update the store data forms."
Google Play explicitly asks you to update your Data safety section and privacy policy as your data handling changes. Twice a year, reread it against your vendor dashboards.
Which traps catch side projects?
Pasting a big company's policy. It describes their data and ad partners, not yours.
Forgetting the quiet tools. Error trackers, chat widgets, embeds and AI APIs often send data you never thought about.
"We collect no data" next to a signup form. An email address is personal data.
Promising what you do not do. "Deleted immediately" when it is not true is worse than saying less.
Different URLs in different places, or a PDF that Google Play will not accept.
A stale date. "Last updated" three years ago, with an AI feature shipped last month.
A made-up example: Rosalind and Wickerlog
Everything here is invented, names and numbers included. Rosalind is a structural engineer who builds Wickerlog in the evenings: a small web app where allotment gardeners log what they planted and harvested and get a monthly summary email. Login is a magic link, there is an optional paid tier through Stripe, and a "suggest what to plant next" button sends a user's planting notes to an AI API.
She first pasted a generator template. It mentioned "advertising partners" and location tracking and kept data "as long as necessary". None of it was true. When she applied for Google OAuth verification to add Sign in with Google, she also found the policy had to live on her own domain and match the consent screen link; hers lived on the generator's site.
So she spent a Tuesday evening on the inventory. Nine rows: email, optional display name, planting notes, harvest entries, payment records at Stripe, cookieless page views, error reports, host request logs and notes sent to the AI provider. Writing the "why" column made her drop one thing: town names left over from a weather feature she had removed months earlier.
The finished policy was about 700 words at /privacy on her domain, dated, linked from the footer, signup and OAuth consent screen. When she swapped error trackers three weeks later, updating it took ten minutes.
A one-weekend plan
When | Do this | Done when |
|---|---|---|
Saturday morning | Walk the product as a new user; search code and dashboards for SDKs, scripts and APIs | A raw list of everything that touches user data |
Saturday afternoon | Fill in the inventory sheet and delete anything collected without a reason | Every row has a "why" |
Sunday morning | Write the seven sections in plain words; check any template line by line | No sentence describes something you do not do |
Sunday afternoon | Publish at one URL, date it, link it from footer, signup and every store or OAuth field | Same link everywhere |
Sunday evening | Set up the privacy email, the request log and the new-tool checklist line | A test email reaches your phone |
Timings are suggestions. A tiny project can do it all in one long evening.
FAQ
Does a free side project need a privacy policy?
Usually, yes. Google Play, the App Store and the Chrome Web Store ask regardless of price, and once you collect an email address, privacy law can apply. Being free changes your risk, not the question.
Can I just use a privacy policy generator?
You can start with one, but check every line against your data inventory and remove anything you do not do. A short accurate policy beats a long one describing someone else's business.
Do I need a lawyer?
For ordinary data, many builders write their own from an honest inventory. If you handle health, financial or children's data, or sign contracts with large customers, an hour of proper advice is worth paying for.
What if I don't collect any personal data?
Check carefully first: hosts keep request logs, and contact emails count. If it is still true, say exactly that in a short dated policy. Google Play requires a privacy policy even then.
Write down what is true, then keep it true
A privacy policy for a side project is a short, dated description of what your project really does with people's data, built from an inventory you can check in an evening and kept honest with one checklist line. And when your project is ready for people who browse side projects on purpose, list it on SideHunt.