Small Users, Big Defaults: Building UK Apps That Pass the Children’s Code Test

Most UK product teams do not set out to build an app that treats children badly. They set out to ship. The Children’s Code — the ICO’s Age Appropriate Design Code — then arrives in a legal review near launch, gets translated into a privacy notice, and everyone hopes the defaults are fine. They often are not.

The code is not a single checkbox. It is a set of design expectations that show up in the first-run journey, the profile screen, the notification permission prompt and the analytics plan. If your app can be used by under-18s, those decisions need an owner before build, not a legal scramble after it.

Where the code lands in the product

Start with age assurance. Not every app needs hard identity checks, but every app used by children needs a proportionate way to know which experience to provide. A neutral age gate is better than a date-of-birth field that quietly blocks anyone under 13 from continuing. Ask what happens when someone says they are 12, 15 or 18, and what happens when they refuse to say. If the answer is 'they get the adult experience', that is a product decision, not a legal one.

Privacy defaults matter more than settings screens. Children should land in the most protective version of the app: profiles private or friends-only, location sharing off, contact discovery off, personalised ads off, and data sharing with third parties limited to what is necessary. Adults can opt in to more. Children should not have to opt out of exposure.

Profiles are where good intentions leak. Display names, avatars, school names, year groups, postcodes and 'friends of friends' visibility all add up. A profile that is harmless for a 30-year-old can be a safeguarding issue for a 14-year-old. Decide who can search for a child, who can message them, who can see their activity and what appears in recommendations.

Notifications deserve their own review. An app that nudges a child at 10pm to 'keep the streak alive' is not just annoying; it is a design choice with wellbeing implications. Check frequency, timing, content and whether notifications reveal information on a locked screen.

Data sharing is the quiet one. Analytics, crash reporting, ad SDKs and attribution tools often collect more than the product team realises. Under-18 accounts should not be feeding precise location, contacts or behavioural profiles into ad tech by default. If you cannot explain what an SDK collects, you cannot defend the default.

A 90-minute review session that catches real problems

You do not need a six-month programme to find the obvious failures. You need the right people in a room with real devices and a journey map.

Invite product, design, engineering, data and whoever owns safeguarding or legal review. Give someone the job of playing a 13-year-old, someone a 16-year-old and someone a parent setting up an account for a younger child. Walk the first-run journey on a real handset, not a Figma prototype.

Step one: screenshot every default. Age gate, permissions, profile visibility, notifications, marketing consent. If a default is not visible in a screenshot, it is probably not understood by the team.

Step two: draw the age assurance decision tree. What does a 12-year-old see? A 15-year-old? An 18-year-old? Someone who lies? Someone who asks to change their age? The tree should have product answers, not shrugs.

Step three: build a profile visibility matrix. Rows are user types; columns are search, messaging, comments, activity, location and recommendations. Fill it in with current behaviour, then mark the gaps.

Step four: audit notifications for the first seven days. Count them. Check quiet hours. Read the copy as if you were a parent.

Step five: list every third-party SDK and what it collects. Mark which ones are active for under-18 accounts. This is often the most uncomfortable part of the session, which is why it belongs in the diary.

Step six: triage red flags into fix-before-build, fix-before-launch and accept-with-evidence. Give each one an owner and a date. A review session without owners is just a workshop with biscuits.

Red flags that still reach store review or procurement

Some issues survive because nobody owns the space between legal, product and engineering. Watch for 'we will add age assurance later', parental consent handled by a single tick box, public profiles by default, contact upload switched on for everyone, and analytics collecting precise location from under-18s. Also watch for dark patterns such as 'share with friends to continue', privacy notices written only for adults, and no clear way for a child to report or block someone.

Store review may not catch all of this. Procurement might. UK buyers and school trusts increasingly ask for evidence of default settings, data flows and safeguarding routes. If your answer is a policy document rather than a tested journey, expect a delay.

The practical move is to make the safe version the boring version. Private by default. Notifications off until asked. Data sharing limited. Age assurance proportionate. Then document the decisions. That is not just compliance; it is a better product for everyone who is not an adult yet.