Most teams assume the ICO’s Age Appropriate Design Code doesn’t apply to them because they aren’t building “a children’s app”. That’s not the test the ICO applies, and it’s worth getting right before the data model is locked in, not after.
Who this actually catches
The Children’s Code applies to any online service that is “likely to be accessed” by someone under 18, whether or not it was designed with children in mind. A family organiser, a general messaging app, a fitness tracker with shared household accounts, a consumer product with no minimum age gate at all — any of these can fall in scope if a reasonable proportion of the realistic user base includes under-18s.
This matters more than a typical compliance checklist because it isn’t a documentation exercise. The Code sets out how the product itself has to behave: default settings, what gets collected, what gets shared with third parties, and how consent and age are established. Get the assessment wrong at the start and you’re reworking data flows later, not just updating a privacy policy.
What “likely to be accessed” means in practice
The ICO doesn’t require certainty that children use your service — it asks whether it’s more probable than not, given the nature of the product, how it’s marketed, and who actually signs up. A B2B expense tool sold to finance teams is a reasonable case for “no”. A family organiser, a general messaging app, or anything built around households, schools, or shared calendars is a much harder case to argue “no” on, and the ICO’s expectation is that you document that reasoning either way rather than assume it.
This is a decision worth making early and in writing, because it changes what gets built. If the honest answer is “yes, plausibly”, the Code’s standards apply to the whole service, not just to accounts flagged as belonging to a minor — in most designs you don’t reliably know which accounts those are until age assurance is already part of the product.
The design decisions it forces
Three defaults tend to change the shape of a build:
- Privacy settings default to high, not low — location sharing, public visibility, and behavioural profiling can’t be the default state a user has to opt out of.
- Data collection has to map to a specific, current feature, not sit “in case it’s useful later” for analytics or future personalisation.
- Nudge techniques — design patterns that push users toward sharing more or weakening privacy settings — are explicitly out, which affects onboarding flows, permission prompts, and upgrade prompt wording.
None of this is exotic if data minimisation is already a habit. What catches teams out is that these defaults have to hold even when they conflict with a feature that’s genuinely useful — geolocation for a family safety feature, for example, still has to be justified and off by default, not on by default because it makes the feature better.
Age assurance is where estimates go wrong
Many project plans budget for a self-declared date-of-birth field and assume that’s sufficient. It generally isn’t, and the ICO’s own guidance has moved further in that direction: self-declaration alone is treated as insufficient for services assessed as higher risk, which pushes toward stronger age verification or estimation — anything from account-linking with a parent, through document checks, to facial age estimation for higher-risk cases.
The engineering cost of this is easy to underestimate at the planning stage. Age assurance isn’t a form field; it’s a subsystem with its own vendor evaluation, data retention questions — age-verification data is still personal data, and often sensitive — and a fallback path for the people it gets wrong. If age assurance shows up as a two-day task on a project plan, that’s a sign the scoping conversation hasn’t happened yet.
This is an engineering decision, not just a legal one
Where this usually goes wrong isn’t bad intent, it’s sequencing: legal review happens after the data model, the analytics events, and the third-party SDKs are already decided, and by then “default to private” or “don’t share with the ad SDK” means reworking things that are already live. The standards in the Code — data minimisation, no profiling by default, restricted third-party sharing, transparency written for the actual audience — are cheaper to design in from the schema and the event-tracking plan than to retrofit after launch.
Building a family organiser ourselves (Assistant Mama AI is ours) makes this concrete rather than theoretical: shared household data, calendars that include children’s schedules, and notifications going to more than one adult all raise the “likely to be accessed” question directly, and the honest answer to it shapes the account model before a line of the sharing logic gets written.
A checklist before you scope the build
- Have you written down, with reasoning, whether under-18s are likely to access the service — rather than assumed it?
- Do your default settings ship private, with sharing and location as opt-in rather than opt-out?
- Can you point to a specific feature for every field you collect, rather than “might be useful later”?
- If you need age assurance, has it been scoped as its own workstream with a named approach, not a form field?
- Does your privacy policy have a version written in language the actual audience, including any younger users, can understand?
- Have onboarding and upgrade prompts been reviewed for nudges that make weaker privacy the path of least resistance?
If most of these are still unanswered once the data model is already built, fixing it stops being a documentation change and starts being a rebuild.