Skip to main content
// FOUNDRY5
Software for under-18s

Gate three of four covers age assurance, consent, safeguarding, children's data and a stricter app store review. The store decision rests with somebody you will never speak to, working from rules you cannot negotiate, and a rejection lands after the launch date is public. You can resubmit, but the announced date has already gone.

What the review asks forSee Ove

✓ The product is built here · Safeguarding stays with the people responsible for children

5Evidence areas we map
2Users who never agree
1Submission date that will not move
The five evidence areas

Five things a children's product has to prove.

An under-18 product has two users who never agree. The fourteen-year-old wants privacy from their parent, the parent wants oversight, and both are being reasonable.

Every consent screen takes a side in that argument. A reviewer will ask which side you took and why, and burying the choice in a settings toggle is the weakest answer available. Settle it first, because everything below follows from it.

Where the line is

  • You own the safeguarding policy

  • You decide what a child can see

  • The product built here enforces both

  • Risk to children is never ours to assess

In Philip's words
On a product for teenagers, the hardest design question is what a parent should not see. Answer it before the first screen is drawn, and the consent flow, the data model and the store listing all follow from that answer.

Philip Wasko

Co-founder, Foundry 5

What the review asks · 01

That you know a user is old enough, rather than that you asked them.

What that means for the build

A date-of-birth field is self-declaration, the online version of a sign on a pub door asking under-18s to stay outside. Where the risk is high, the ICO expects a step a thirteen-year-old cannot pass by typing a different year, and a reviewer spots the difference straight away.

What the review asks · 02

Whose consent you relied on, for what, and how you would prove it a year later.

What that means for the build

Some accounts rest on the young person's consent, some on a parent's, some on both. The product records which applied to which account and when it changed, because it changes on a birthday whether or not anyone is watching.

What the review asks · 03

What happens when something goes wrong, and who is at the other end of it.

What that means for the build

A reporting route has four parts: the form, a named person, a response time and a record. Until somebody is named, the route does not exist, however good the form looks.

What the review asks · 04

What you collect from a minor, how long you keep it, and what you deliberately never collect.

What that means for the build

Data created by somebody who was a child at the time needs its own retention and deletion rules. The Children's Code calls the harder half data minimisation: what you chose not to store, and proof that the choice was deliberate.

What the review asks · 05

That the product fits the store rules before you submit, because after you submit is too late.

What that means for the build

Apple's Kids Category and Google Play's Families policy both check the rating you declare against what the app shows. Your listing's data declarations have to match what you collect, and your screenshots tell the reviewer who the product is for before they open it.

Who this is not for

When we say no to a children's build.

On work for young people, accountability outranks payment. A team the studio does not direct is a team whose safeguarding decisions nobody here can stand behind.

Read why, and where we send each one instead
Where it goes wrong

How careful teams still get rejected at the store.

Each comes from a team that took the responsibility seriously and built a product that could not show it.

01 Field

Age is a profile field

It sits next to name and email, editable, unverified and worth nothing to a reviewer. The product knows what somebody typed and has never known how old they are.

02 Retrofit

Consent was designed for the adult first

Somebody built the grown-up flow first and bolted a parental branch beside it near the end. The seams show, and reviewers look at seams first.

03 Owner

The reporting route has no other end

There is a button. Where the report lands, who reads it and how fast they answer were left for later, and the submission arrived before later did.

04 Assumed

Submission was scheduled as a formality

The launch date assumed approval. Nobody costed a rejection, so the first one ate the buffer and the second ate the launch.

The Week-One Review

A week that settles consent before anyone draws a screen.

The under-18 version starts from who your users are, what has to be true before any of them can open the product, and what a store reviewer sees opening it cold, with no context and no goodwill.

  • Day 1 · Name the gate: the age bands, the consent model and the submission date
  • Day 2 · List the evidence: what age assurance, consent and safeguarding each have to show
  • Day 3 · Test the plan: your current flows, walked through as a reviewer will, cold
  • Day 4 · Decide the sequence: what must exist before submission, and what waits for version two
  • Day 5 · Price it: a build sequence, a submission plan and a fixed quote

5 days

The fee is quoted before you start and credited against the build when you proceed.

What you walk away with

A consent model and a submission plan, written down.

Yours to keep whether or not you build with us, and usable by any supplier.

  • A consent model on paper, including the cases where both consents apply
  • An age assurance approach chosen and justified
  • A safeguarding route with a named person at the other end
  • A submission plan with room for at least one rejection
The full method, day by day → Not sure the under-18 gate is yours? Check in six questions →
The proof

Ove, and the users who were fourteen.

Ove is a health app for teenage girls going through puberty, so its users sit inside every rule on this page. An adult health app can assume the user and the person who agreed to it are the same. Ove could not, and its users do not always want a parent to see what they looked up.

Four questions were settled before the interface: who consents, what a parent can see, what the product collects and deliberately leaves out, and what happens when a young person reports something. The answers shaped the build, so nothing needed writing up afterwards.

It passed 15,000 downloads inside its first quarter.

Read the Ove Care case study
Ove Care puberty support app
Under-18 and App Store

Ove Care

15K+

Downloads in first quarter

The regulatory loading

The age bands you serve set the price.

Under-18 work can start at Band 1, because the product surface is narrower than a financial or clinical build. The loading comes from breadth: how many age bands you serve, and whether adults and minors share one product.

One teenage cohort is a contained build. Thirteen-year-olds, seventeen-year-olds and their parents in one product means every screen has to know who is looking at it.

Ask for a quote
Band 1 · Gated MVP

Quoted after the Week-One Review

  • Designed backwards from the review
  • Evidence produced during the build
  • Scope cut to what the gate requires
  • Handover documentation included
Under-18 questions

Questions from teams building for teenagers.

All six are about building the product. None of them is safeguarding advice, and we will keep saying so.

Enough to match the risk. Self-declaration is the easiest form to get round, estimation and verification are harder, and the ICO expects the method to be proportionate to what your product does. Decide before the build, while changing it costs a conversation instead of a rebuild.

To every part a minor can reach, which is more of the product than most teams expect. Draw that boundary before the build, because finding it during a review costs a resubmission.

You do, with a named person in place before launch. The route, the record and the response tracking get built here. Staffing the other end stays with you, and you will hear that said plainly.

As an event the product plans for, not a birthday it notices afterwards. Consent, retention and what the account can do all change on that date, and somebody may ask what happened to the record of the child they used to be.

The rating against your real content, your data declarations against what you collect, sign-in requirements, and what the screenshots imply about the audience. The gap between what a listing says and what a build does is a common place to come unstuck.

Yes. Who pays and who uses are separate questions, and the expectations follow the user, not the card.

Two users / One submission date / Room for a rejection

Tell us the age bands, the stores and the submission date.

The age bands decide the consent model, the stores decide the rules you build to, and the date decides how much room the plan keeps for a rejection. Send all three and you will get a straight answer on whether this is a build we should take on.

Tell us who your users are →Back to regulated software →

NOT SAFEGUARDING ADVICE / THE PEOPLE RESPONSIBLE FOR CHILDREN STAY RESPONSIBLE