Most apps treat privacy as a document. Build the product, add analytics, add accounts, add a privacy policy, then explain the data flow after the fact.
That feels backwards when the users are children.
When I built Tuniri, the question was not “How do we collect data responsibly?” It was simpler: what can we avoid collecting at all?
For a learning app aimed at children aged 2-6, that question changes the architecture. No account system. No analytics SDK. No ad SDK. No remote progress sync. No server holding a child’s learning history. The privacy promise had to live in the codebase, not only in the copy.
Privacy is easier when there is less to explain
There is a kind of privacy work that happens after the product is already complicated. You document processors. You explain retention. You map third-party SDKs. You write deletion flows for data that maybe did not need to exist.
Sometimes that complexity is necessary. For Tuniri, most of it was not.
The first design pass looked like this:
Need: learning progress
Default app answer: user account + backend profile
Tuniri answer: local SQLite database
Need: usage insights
Default app answer: analytics events
Tuniri answer: no analytics SDK
Need: monetization
Default app answer: ads or tracking-based funnels
Tuniri answer: no ads
Need: parent review
Default app answer: cloud dashboard
Tuniri answer: on-device Parent DashboardThat is not a legal strategy by itself. But it is a strong engineering starting point. Every data flow you remove is one less thing to secure, explain, audit, retain, export, or delete later.
The zero SDK rule
The easiest way to leak data from a mobile app is not usually the code you wrote. It is the SDK you installed and forgot about.
Analytics SDKs, ad SDKs, attribution SDKs, crash reporters, social login packages: all of them can be useful in the right product. In a children’s app, each one deserves suspicion before it earns a place in the build.
Tuniri uses a simple rule: if the app can work without a third-party SDK that observes user behavior, leave it out.
That means giving up some convenience. You do not get nice dashboards showing session length, feature funnels, or retention curves. You also avoid a whole category of questions:
- What identifiers does this SDK create?
- Does it send device metadata?
- Does it collect usage events by default?
- Can parents opt out?
- Where does the data go?
- What happens if the vendor changes behavior later?
The build becomes easier to reason about because the dependency tree is smaller. flutter pub deps is part of the privacy review, not just a debugging command.
Local data still needs protection
“No server” does not mean “no privacy work.”
Tuniri still stores learning progress, profile settings, session history, and Parent Dashboard data on the device. That data is not being sent to a backend, but it still belongs to the child and family.
The local design has three rules:
- Store only what the app needs to function.
- Keep each child profile separate.
- Make deletion obvious to the parent.
Progress lives in SQLite. The database is encrypted at rest with AES-256, with the key stored through the platform keychain on iOS and Android Keystore on Android. Parents can delete a child’s profile and remove that child’s local progress.
This is less glamorous than a cloud architecture diagram, but it is the part that matters. Privacy-first does not mean refusing to store anything. It means being strict about why data exists, where it lives, and how it goes away.
Parent controls without child accounts
A child should not need an account to learn letters, numbers, or phonics.
That one decision removed a surprising amount of product surface. No signup. No password reset. No email verification. No profile photo upload. No marketing email. No remote identity to protect.
The Parent Dashboard stays on-device. It shows session history and learning progress without sending anything to a web service. A simple math gate separates the child-facing experience from parent-only screens. It is not pretending to be banking-grade security. It is an age-appropriate barrier for a 2-6 learning app.
The important bit is that parent controls do not require child accounts. The app can still support multiple child profiles on one device, but those profiles are local records, not cloud identities.
Compliance should not be the first line of defense
COPPA, GDPR safeguards for children, Apple App Store rules, and Google Play Families policies all matter if you build for children. The FTC explains COPPA as giving parents control over information collected from children under 13. The European Commission notes that services aimed at children need clear language and special safeguards. Apple and Google both put extra pressure on data practices for apps used by children.
I do not treat that as a checklist to satisfy at the end.
The better engineering question is: can the architecture make the review smaller?
If there is no ad SDK, there is no ad-tracking data flow to explain. If there is no account system, there is no child email address to protect. If progress never leaves the device, there is no server-side learning profile to export or breach.
You still need policies. You still need platform disclosures. You still need to understand the rules for the markets you ship in. But the cleanest privacy answer is often architectural: we do not collect that.
The tradeoff is product visibility
The downside is real. Without analytics, you lose easy visibility into usage.
You do not know exactly where children drop out of a lesson. You do not get automatic crash streams with device fingerprints. You cannot run normal growth experiments. You cannot answer every product question with a dashboard.
For Tuniri, that was acceptable. The target user is a child. The buyer is a parent. Trust is more important than funnel precision.
There are still privacy-respecting ways to learn: parent feedback, app-store reviews, manual testing, support emails, and opt-in research builds. They are slower. They are also easier to explain honestly.
What I would watch next
The hardest future decision is content delivery.
Right now, bundling content inside the app keeps the privacy story simple. The app works after install, without fetching lessons from a server. The cost is app size and slower content updates.
A future content-pack system could still be privacy-first, but it would need strict boundaries:
- Download content without account identity
- Avoid per-child progress sync
- Keep learning records local
- Make the first-launch experience clear for parents
- Keep third-party services out of the child data path
That is the shape of the problem. The goal is not to avoid every network request forever. The goal is to avoid turning a children’s learning app into a data collection system.
The lesson
Privacy-first development is mostly subtraction.
Remove the account if the app does not need one. Remove analytics if the trust cost is too high. Remove SDKs that make the dependency tree harder to explain. Keep data local when local is enough. Encrypt what remains. Make deletion simple.
For Tuniri, the strongest privacy feature is not a toggle. It is the absence of unnecessary data flow.