Privacy-first app design: lessons from building a children's app

Talkable helps children communicate with picture tiles, follow visual daily routines and take calm-down breaks. Building it meant designing for two users at once, a child and a parent, in one of the most sensitive categories there is.

Children's apps face stricter app store review, stricter laws and, rightly, much more cautious parents. The same is true, to different degrees, for health, finance and anything involving personal documents. Here's what we learned.

Keep data on the device when you can

Talkable keeps children's photos, voice recordings, schedules and check-ins on the device. There's no account to create.

That decision did a lot of work at once:

• Less to protect. Data that never reaches a server can't leak from one.
• Simpler to explain. "Your child's photos stay on this device" is a promise parents understand instantly.
• Cheaper to run. No storage costs for user content and fewer moving parts.
• Easier compliance. Fewer questions about where data lives and who can access it.

Ask early whether your product truly needs a server for user data. Often the honest answer is "only for some features", and you can design around that.

Separate the child's experience from the parent's

Talkable's kid mode has big, calm screens, no purchases and no ads on the child's content. Everything that changes settings or spends money sits behind a parent PIN, with optional Face ID.

This isn't just good manners. Store rules for children's apps restrict purchases and links that a child could reach. Designing the split from the start is far easier than retrofitting it.

Every SDK you add is a promise

Analytics, crash reporting, payments, attribution: each third-party SDK collects something, and each one has to be accurately described in your privacy policy and store privacy labels. In children's apps, some kinds of third-party analytics and advertising are restricted altogether.

Our rule: list every SDK and what it collects before launch, and review the list whenever you add a dependency. If you can't explain why a tool needs the data it collects, remove it or configure it to collect less.

Write the privacy policy alongside the product

Privacy policies are often written last, copied from a template, and forgotten. That's backwards. Writing the policy while you design the product forces the right questions: what do we collect, why, where does it go, how long do we keep it, and how can users delete it?

When the product changes (a new feature, a new service, a new kind of data), the policy changes with it.

Make privacy visible

If you've done the work, say so clearly in the store listing and onboarding. Talkable's store description leads with privacy because it's one of the main reasons a cautious parent chooses it.

The lesson for every product

Privacy isn't only for children's apps. In any category where trust matters, it's a feature users choose you for, and a liability if you get it wrong. The cheapest time to get it right is at the very start.

Building in a sensitive category? Talk to us before you build. Getting the data design right early saves painful rework later.