Series: Weekend at Claude's — misadventures in building a production app with an AI anyone could mistake for the person who's going to make the whole thing happen
Nobody gets excited about a Terms of Service screen.
It's not the feature you demo to impress investors. It's not the thing you describe when you explain what the app does. It's the screen that sits between "download" and "use," and its entire job is to make users agree to something they're probably not going to read.
And yet.
If you're building a real product — one with real users, a real privacy policy, and any ambition of being in the App Store — the consent screen is load-bearing. It's where you establish legal consent, set the age gate, and create the paper trail that proves a real human accepted your terms on a specific date in a specific version. Get it wrong, and you've got GDPR exposure, App Store rejection risk, and a legal document that might not hold up if you ever need it to.
I knew this needed to be done. I didn't know how much thinking it involved until I sat down with Claude to do it.
What I asked for
My actual ask, typed on my phone in a few sentences: draft the Terms of Service and Privacy Policy, sketch out the launch screen UI, and write a blurb for the Report Content button for Claude Code.
What came back was a complete Terms of Service, a complete Privacy Policy, a full UI specification for the consent screen with explicit decisions on every design choice, a re-consent flow for when the terms get updated, a Settings → Legal screen spec, and a complete Claude Code prompt to implement all of it.
The ask is a paragraph. The output is an afternoon of work. This is the pattern.
The decisions that actually mattered
The thing I didn't expect was how many real decisions were embedded in something that looks simple on the surface.
Dedicated screen vs. popup. Industry standard is a dedicated full screen before account creation — not a modal, not a cookie banner, not a checkbox buried in the sign-up form. The reason isn't just UX. It's that a dismissable popup creates a weaker legal record than a screen the user explicitly had to navigate through. We went with the dedicated screen.
Age gate: 18+, not 13+. The initial draft had a 13+ gate, which is the COPPA minimum. But Aphilaty is an adult platform. When a school uses Aphilaty, it's teachers communicating with parents — not with students. That's a meaningful distinction legally: 18+ eliminates COPPA complexity entirely and makes the child-directed content declaration in both the App Store and Play Store a clean "no." One conversation, one decision, one significant reduction in compliance surface area.
Both checkboxes required, no partial acceptance. GDPR requires unambiguous, informed consent. Two explicit checkboxes — one for ToS/Privacy Policy, one for the age gate — and the Continue button is disabled until both are checked. No exceptions.
In-app sheets for the documents. When the user taps "Terms of Service," it opens as a scrollable sheet inside the app rather than launching a browser. The Continue button stays disabled while the sheet is open. This one sounds like a minor UX detail but it matters: you want a complete read-through to be the path of least resistance, not something that breaks the flow.
Firestore for consent state, not AsyncStorage. This was a near-miss. AsyncStorage doesn't survive an app reinstall. If consent state lives there, a reinstall looks like a new user and the screen re-appears — which is both annoying and potentially creates a duplicate consent record. All user state in Aphilaty lives in Firestore. This is consistent with that pattern and correct for the same reasons.
Append-only audit log via Cloud Function. When a user accepts the terms, it writes tosAcceptedVersion and tosAcceptedAt to their user document. It also calls a Cloud Function that appends a record to legal_audit_log — a Firestore collection with no client read or write access, ever. The audit trail is immutable by design.
The re-consent flow
The part I hadn't thought about before starting: what happens when the terms change?
The answer is: every user sees a re-consent screen on their next app launch, and they can't proceed until they accept again. The screen shows an amber banner summarizing what changed and the effective dates. The tosAcceptedVersion string is bumped in legal.ts, and every existing user whose stored version doesn't match the current version gets the blocking screen.
This is a GDPR requirement for material updates. It's also the kind of thing that's annoying to retrofit if you don't build it in from the start. We built it in from the start.
The screen nobody notices
Here's the thing about getting this right: users will never notice.
A well-designed consent screen is one that users move through quickly, understand clearly, and don't think about again. They check two boxes, tap Continue, and they're in. The legal record is created. The age gate is enforced. The audit trail exists.
The screens that get noticed are the ones that feel like traps — the dark-pattern "agree or leave" dialogs, the checkboxes pre-checked, the ToS link that opens a 47-page PDF with no scroll indicator. Those screens exist because someone decided the legal obligation was the enemy of the product experience.
The consent screen we designed is short. It says exactly what it is. The documents open in-app so you can read them without losing your place. The privacy tagline at the bottom is one sentence: "Aphilaty never sells your data. Anonymous offer matching is opt-in and can be disabled at any time."
If a user reads that and decides not to proceed, that's a feature, not a bug. Informed consent only counts if the information is actually there.
The lesson
The unglamorous work is still work. The consent screen is never going to be a blog post headline or an investor demo moment. But it's load-bearing in a way that most features aren't. Get it wrong and the app doesn't ship. Get it right and no one ever thinks about it again.
That's a reasonable outcome for a Terms of Service screen. Make it invisible by making it correct.
Aphilaty is a privacy-first community coordination app. aphilaty.com