Indie-Site Essentials: How to Write Your Privacy Policy, Terms of Service, and Refund Policy

Many indie sites treat these three documents as a pre-launch “formality,” copying an English template through machine translation and hanging it up. Then payment review asks questions, ad review rejects them, and they fail at the first gate. This covers what each document actually needs to say — written against this site's own three pages, all real practices in use.

Why these three can't be skipped

Three parties read them: payment-platform review (e.g. Creem) checks your refund policy and whether the support email matches; ad platforms (e.g. AdSense) check whether the site discloses information completely; careful users click through before paying. Missing any one of them signals “this site isn’t serious.”

Privacy policy: say four things clearly

• ·What you collect: registration emails, order info, content users write themselves — list them; don't wave them away with “and other information”
• ·Where it's stored and who sees it: e.g. support sees your email when handling tickets, operations sees error logs
• ·What it's used for: only to deliver the service you bought — no selling data, no repurposing
• ·What rights users have: want to export, want to delete — who to contact (give an email) and how fast you'll reply

This site's approach as a reference: our guide states that the ideas and answers you write are stored on the server and used only to generate your project package — never executed as code; and things like database passwords and payment keys shouldn't be written into ideas or answers. Write in the policy what you actually do; if the two don't match, the writing is wasted.

Terms of service: draw the line between “what we provide and what we don't”

The core of terms of service is one sentence: draw the boundaries clearly. What you provide (e.g. template project package download, documentation guidance after download), what you don't (e.g. we don't offer done-for-you launches, we don't run users' code), and account rules (one account per person, don't share passwords). The clearer the boundaries, the fewer the disputes. Vague terms won't help you when you argue.

Refund policy: digital goods need finer print

Physical goods can be returned; digital goods are “used” the moment they're downloaded — so the refund policy must be written finer: under what conditions you refund (e.g. duplicate charges, cancellation before download), who to contact (the support email), how fast the money arrives. Don't write “all sales final” — it looks tough, but platforms don't honor it in real disputes; clear rules are better for both sides. Let users see the policy before checkout — don't hide it in a third-level menu.

Three implementation checkpoints

• ·The footer links to all three from every page, tappable on phones too (this site's footer links are all 44px tall on mobile)
• ·The support email is real, valid, and consistent site-wide: the legal pages, the footer, and the payment platform must all show the same one
• ·Copy matches reality: don't write “24/7 support” when it's one inbox; don't write “refund anytime” when only duplicate charges are refunded

Once the three are written, do one thing by hand: play a first-time visitor, click through the footer links from the homepage, and confirm each opens and reads clearly. Ten minutes of yours saves weeks of back-and-forth in review.

How to write the support email's auto-reply

A support@-style support inbox is read by a human, but humans aren't online 24 hours. The auto-reply's job isn't “customer service” — it's telling the user “I got your email, it won't sink without a trace.” Three sentences are enough: confirm receipt, say how fast you'll reply (e.g. “we reply within 2 business days”), and what to do in emergencies (e.g. “for payment issues, put [Payment] in the subject — we'll prioritize it”).

Don't promise what the auto-reply can't deliver. “24/7 live support” paired with an inbox checked twice a day teaches users disappointment. Write “reply within 2 business days,” then actually reply within a day, and users feel over-delivered. Managing expectations is half of support work; the other half is actually solving problems.

When a user asks for data deletion: what you actually do

When a user writes “delete all my data,” don't reply “sure” and delete one database row. Follow this checklist: first verify identity (the email came from the registered address, or they operate while logged in); list what to delete: the account, order records, content they wrote; before deleting, ask yourself: is any of it legally required to be kept (order records for tax purposes usually must be kept for years — that belongs in the privacy policy); data in backups: state that backups are kept 7 days and auto-overwritten — you won't dig one record out of a backup. That line must be in the policy ahead of time, or it's a lie.

After deleting, send a confirmation email: what was deleted, when, and when backups roll over. That email is what the user actually wants. Log the whole process as a ticket — if there's a dispute later, you have records. Remember the order: verify identity before acting, and check what the policy promised before deleting — don't promise one thing in the policy and do another.

When the terms change: how to notify users

Terms aren't written once for life — price changes, new features, new payment methods can all require edits. Two kinds: small (typos, the support email changed) — just edit and update the “last updated” date on the page; big (you start collecting new data, refund rules changed) — notify ahead and give users a choice: on-site announcement plus email, 15 to 30 days ahead; users who disagree can cancel and get refunded.

Every update, keep the old version — one commit in git is enough. When a user asks “didn't you used to say something different,” producing the old version is professionalism. Don't write the notification email as an essay: which clause changed, the impact in one sentence, what to do if you disagree — three paragraphs suffice. Write more and nobody reads it, which equals no notification.

Refund disputes: the support script

When a user actually asks for a refund, read the refund policy first, then the order records, and follow the rules — don't argue with the user over email. If they qualify, refund promptly and send a confirmation afterward; if not, quote the relevant clause from the policy — polite tone, firm stance. Most disputes are “didn't read the rules,” not “deliberately picking a fight.” Log each one afterward: which rule was unclear enough to cause this dispute, and fix it in the next policy update.

Where to put the policy pages: don't hide them

However well written, policies users can't find might as well not exist. The footer needs an entry on every page, tappable on phones; link the refund policy once more on the checkout pages — users seeing the rules before paying halves disputes. Don't bury them in a third-level menu or fake them with tiny light-gray text — reviewers look at whether those entries exist first.

Cookie policy: to pop up or not

If you use third-party analytics (like GA4) or ad code, show a cookie-consent banner — that's the compliance requirement. If you only use your own necessary cookies (like login state), you can skip it. Don't design the banner so “disagree” can't close it — that's thuggery and brings the same trouble when reported. Cloudflare's built-in analytics is cookie-free and can skip the banner — one reason to choose lightweight analytics.

Minors: don't go there

Collecting children's information is a red line — don't touch it. If you don't know users' ages, don't collect birthdays, schools, and the like — echoing the “Adding a Field” post: fewer fields, less risk. If your product is clearly for adults, state “this service is for adults” in the terms — one more layer of protection. The cheapest compliance move is always “don't collect.”

Where the data lives: tell users

Which country the server is in, how long backups are kept — put it in the privacy policy. When you switch datacenters or providers, update the policy. Users may not read it, but reviewers will, and you should be able to answer when asked. Cross-border data is a sensitive topic — write where the server is, no vagueness. Written clearly, users trust you; written vaguely, questions become trouble.

Account deletion: give them a door

When users want to leave, don't make it hard. Put a deletion entry in account settings that explains: which data gets deleted after cancellation, how fast, and what is kept for legal reasons and how long. Don't make users email to cancel — that design looks like retention but actually accumulates bad reviews. Part on good terms; a user who leaves may come back, but a burned bridge never does.

Policy versions: keep copies

Every policy update, keep the old version — one git commit is enough. When a user asks “didn't you used to say something different,” producing the old version is professionalism. Put the update date at the top of the page; don't make users guess which year's version this is. A small habit with big effect — it can save you in a dispute.