The most common mistake in software for under-18s is treating age as a form field. A date of birth sits next to name and email, editable, unverified, and worth nothing to a reviewer. The product knows what someone typed. It has never known how old they are.
That gap is where most of the trouble starts, because everything downstream — consent, data retention, the store listing — assumes the age is real. Here are the other mistakes that tend to arrive with it.
Designing the adult flow first
A team builds the grown-up experience, gets it working, then bolts a parental branch on near the end. The seams show. Reviewers look at seams first, because a consent flow that was retrofitted tells them how much thought the rest of the product got.
The deeper issue is that a children's product has two users who never agree. A teenager wants privacy from a parent; the parent wants oversight. Both are being reasonable. Every consent screen takes a side in that argument, and burying the choice in a settings toggle is the weakest answer available. Teams that defer this decision end up rebuilding the data model once they finally make it.
A reporting route with nothing at the other end
There's a button. It looks like safeguarding. Where the report lands, who reads it and how quickly they respond were left for later — and the submission arrived before later did.
A reporting route has four parts: the form, a named person, a response time and a record. Until somebody is named, the route doesn't exist, however polished the form looks. This is the mistake that carries the most weight, because it's the one where the failure isn't a rejection but a child using a feature that leads nowhere.
Treating consent as a single event
Some accounts rest on the young person's consent, some on a parent's, some on both. Teams often record that consent was given without recording which kind applied to which account, or when it changed.
It changes on a birthday, whether or not anyone is watching. A product that can't say whose consent it relied on, for what, and how it would prove that a year later is a product that can't answer a straightforward reviewer question. The Children's Code also asks the harder half of data minimisation: what you chose not to store, and evidence that the choice was deliberate. Teams rarely plan for that.
Scheduling submission as a formality
The launch date assumes approval. Nobody costs a rejection, so the first one eats the buffer and the second eats the launch.
The store decision rests with someone you'll never speak to, working from rules you can't negotiate. Apple's Kids Category and Google Play's Families policy both check the declared rating against what the app shows. Your data declarations have to match what you collect, and your screenshots tell the reviewer who the product is for before they open it. None of that is a formality, and a rejection lands after the date is public.
What a good result looks like
A children's product that survives review tends to share a few traits. It can show age assurance rather than self-declaration. It records which consent model applied to which account and when it shifted. It has a safeguarding route with a named owner on the other side. And its store listing matches the product, so the reviewer opening it cold sees what the team intended.
The build is the easy part. Proving the decisions behind it is where the work sits.
The full guide, including the week that settles consent before anyone draws a screen, is at building software for under-18s.
