Writing an RFP for a children's product: twenty-five clauses an ordinary app tender lacks

What does an RFP for a children's product need that an ordinary app tender lacks?

A children's product RFP needs fourteen clause groups rarely found in an adult app tender: age band, safeguarding, the parent's role, privacy, accessibility, content, moderation, testing with children, measurement, guardrail indicators, consent, incident handling, session end, and success criteria. The reason is simple: the buyer is not only purchasing a technical feature, but contracting for a duty of care toward someone who cannot negotiate for themselves.

How does this document differ from the questions for a first meeting with a studio?

We previously published Ten questions to ask before commissioning a studio, questions for an informal first conversation across six axes: the goal, measurement, safety, consent, ownership, and what happens after launch. This document is the next stage: it turns that conversation's answers into enforceable contract language, and adds groups a first conversation does not need, such as accessibility and the details of incident handling and session end. If the ten questions reveal whether a studio deserves trust, these twenty-five clauses write that trust into a text that does not depend on memory or goodwill.

What are the twenty-five clauses?

Age band

1. A precise age band spanning no more than two adjacent groups, not a broad range running from early childhood to adolescence at once.
2. The method used to verify a user's age at sign-up, and how strict it needs to be given how sensitive the content is.

Safeguarding

3. A clear disclosure policy for when a child writes or says something related to possible harm, with an escalation path to a qualified human.
4. A prior security review of any third party that interacts directly with the child, such as a chatbot, a community, or a voice room.

The parent's role

5. One clear channel where a parent sees a summary of what the child is doing, not only a raw log that needs interpreting.
6. A real ability for the parent to change settings or delete the account without complicated procedures.

Privacy

7. A list of every data field collected about the child, why it is collected, and its deletion date.
8. A written commitment not to sell the child's data or share it with any advertising party.

Accessibility

9. Screen reader support and visual contrast for a child with a visual or motor disability.
10. A simplified audio or text alternative for any complex instruction inside the experience.

Content

11. A clear editorial policy for user-generated content, where that kind of content exists at all.
12. A language review in a register close to how a child actually speaks, not a literal translation from English.

Moderation

13. A human moderation team over any live communication between children, not automated filtering alone.
14. A stated response time for any report raised by a child or a parent.

Testing with children

15. At least one test session with real children from the target age band before launch.
16. Two documented prior consents, from the parent and from the child themselves, for every test session.

Measurement

17. The definition of at least one proximal success indicator, measurable within the contract's own term.
18. A periodic measurement report that clearly separates what was observed from what was actually measured with a named instrument.

Guardrail indicators

19. At least one possible harm identified and watched by name throughout the operating period, not left to chance.
20. A stop or escalation mechanism if the guardrail indicator crosses a threshold stated in advance in the contract.

Consent

21. A written consent form for the parent explaining what is collected and why, plus a separate consent from the child in their own words.

Incident handling

22. A stated response plan for a data incident or inappropriate content, including notifying the parent within a defined period.

Session end

23. A clear design for how a session ends, with no endless feed and no notification designed to pull the child straight back in.

Success criteria

24. A success criterion written into the body of the contract that describes a change in the child, not only a download or visit count.
25. A shared review schedule between the buyer and the studio after launch, at a stated interval from the contract's signature.

What is a good clause, and what deserves rewriting?

An illustrative example of a good clause: "The vendor provides the buyer, within ten working days of signature, with a list of every data field collected about the child, its purpose, and its deletion date, updated whenever it changes." A verifiable clause, with a deadline and a clear consequence if not met.

An illustrative example worth rewriting: "The vendor commits to the highest available standards of privacy and security." No one can violate or verify this clause, because it never states what is actually collected, when it is deleted, or who reviews the commitment. A tender full of clauses of this second kind looks careful while carrying no actual weight.

What are the limits of this list?

This is Dawani's own internal practice, not a ready-to-sign legal template. Each of the twenty-five clauses needs review from a legal advisor who knows the buyer's regulatory system and jurisdiction, especially the privacy and consent clauses, whose details differ from one jurisdiction to another. This list makes sure the right question gets asked; it does not pre-write the correct legal answer.

Where should you start?

Start with the four groups that matter most to your project: safeguarding, privacy, testing with children, and guardrail indicators, then complete the rest before the contract is signed, not after. You can read the Dawani Child-Safe Design framework for a deeper look at the safeguarding axes, or What makes a parent trust a children's product if your tender concerns a product that faces parents directly. You can tell us about your project through the Start a project form.

References

No external source is cited in this article; the twenty-five clauses are Dawani's own internal practice (evidence level: D), not an official government or regulatory standard in any jurisdiction.

Quick questions

Must all twenty-five clauses appear in the first RFP a buyer ever writes?

No. The four most important groups, safeguarding, privacy, testing with children and guardrail indicators, come first, and the rest are completed before the contract is signed, not before the first draft.

Who writes these clauses inside the buyer's organization: legal or the product team?

Both together. The product team knows the details of the child's experience and the purpose of each data field, and legal turns that into enforceable wording that fits the buyer's own regulatory system.

Does this list fit any children's product, or only apps?

It fits any format: an app, a game, a real-world experience, or a device. Some clauses, such as session end, translate differently in a real-world experience, but the same question still needs asking in every format.