Summary
- Why Specificity Beats a Generic Template
- The Notiwise Investment
- The Pilotflow Process: 4 Steps, 15 Minutes
- What Gmail Add-on Legal Documents Must Actually Say
- The Pilotflow Series, Complete
📝 Note
📚 Pilotflow Pre-Launch Series
- The $50,000 Gmail Add-on Myth
- Gmail OAuth Scopes Decoded
- Pre-Development Codebase Review
- Legal Documents in 15 Minutes ← you are here
The first time I wrote a Privacy Policy and Terms of Service for a Gmail add-on, it took two hours. The second time, fifteen minutes. The difference wasn’t skill. It was that the first two hours produced templates, and the second fifteen minutes just filled them in.
Google requires a Privacy Policy URL and a Terms of Service URL before you can configure an OAuth consent screen, and both links sit right there on the screen your user sees before they install anything. They’re not decorative, and Google’s reviewers actually read them. A vague policy is one of the more common reasons a Workspace Marketplace submission gets rejected.
Why Specificity Beats a Generic Template
“We may collect data to improve our services” tells a reviewer nothing. “We read the subject, sender, and date of emails in your inbox. We do not store email body content” tells them exactly what your add-on does and doesn’t touch. For an add-on requesting sensitive Gmail permissions, that second sentence is also the one your actual users want before they click “Allow.” The documents serve both readers at once, and a generic template serves neither.
The Notiwise Investment
Building Notiwise, I spent two hours writing these from scratch: finding SaaS templates that fit Google Workspace’s requirements, correcting them to match what the add-on actually does, formatting for the Jekyll corporate site, deploying, and verifying the URLs resolved. That session’s real output wasn’t two documents. It was reusable Handlebars templates with ,, and `` swapped in for whatever came next. The structure, section order, and scope-specific phrasing were all captured once so I’d never have to think about them again.
The Pilotflow Process: 4 Steps, 15 Minutes
Step 1: locate the Notiwise templates (3 minutes). They were already documented in the Notiwise project file. Finding them took less time than opening a blank document would have.
Step 2: identify the substitutions (8 minutes). Two categories, nothing else. Product identity: Notiwise → Pilotflow by Zippy, with URLs and the support address updated to match. Scope-specific language: Pilotflow’s seven scopes aren’t Notiwise’s, so every scope description in the Privacy Policy got rewritten to match. That’s mechanical work, not judgment work, because the pre-development OAuth analysis had already documented exactly what each scope accesses.
Step 3: deploy via GitHub API (4 minutes). The corporate site is Jekyll (BrightSoftwares/corporate-website), and the GitHub Contents API writes files there directly. No local clone required:
CONTENT=$(base64 -w 0 pilotflow-privacy-policy.md)
curl -s -X PUT \
-H "Authorization: token ${GITHUB_TOKEN}" \
-H "Content-Type: application/json" \
"https://api.github.com/repos/BrightSoftwares/corporate-website/contents/_pages/pilotflow-by-zippy-privacy-policy.md" \
-d "{\"message\": \"Add Pilotflow privacy policy\", \"content\": \"${CONTENT}\"}"
Both files landed at predictable URLs: bright-softwares.com/pilotflow-by-zippy/privacy/ and /terms/.
Step 4: verify (0 extra minutes). Jekyll builds in 2–3 minutes after the push; an HTTP check confirms both URLs return 200 before they go into the Google Cloud Console OAuth consent screen config.
What Gmail Add-on Legal Documents Must Actually Say
For anyone doing this for the first time, the Privacy Policy needs five things stated plainly, not implied: exactly which OAuth scopes you use, in plain language (“we can view and modify the labels applied to your email messages” for gmail.labels, not “we access Gmail data”); exactly what you store, and if the answer is “nothing beyond PropertiesService keys,” say that outright, because users assume the worst by default; what you actually do with the access, matching the add-on’s real behavior and nothing more generous; what happens on uninstall (for Apps Script add-ons, that PropertiesService keys get cleared); and a support email you actually monitor, not a placeholder.
The Terms of Service is where most add-ons cut corners, and the section that matters is liability specific to what your add-on actually does. For Pilotflow, that meant explicit clauses about archiving (what happens if an archive action moves an email the user still needed) and forwarding (what happens if a rule forwards something to the wrong recipient). A generic SaaS ToS template has never heard of either scenario.
The Pilotflow Series, Complete
This four-post series covered the full pre-launch research for a Gmail add-on: correcting the CASA certification cost myth, decoding the three-tier OAuth scope system, reading the existing codebase before writing new code, and, in this post, turning two hours of legal-document work into fifteen minutes by templating it once and reusing it every time after.
Next up: the asset generation system that produces logos, blog images, and social cards for every product in the portfolio.
← Previous: Pre-Development Codebase Review
— Kékéli
