Builder Kin
Kids build websites with AI, and nothing goes online until a parent approves
We proposed and built Builder Kin, an AI builder where children make websites and games from a sentence. Safety rules sit in the backend that generates, games match the child's age band, and a parent controls publishing, screen time and a PIN lock.
EdTechChild-safe AI website builderBuilt from zero
The challenge
Generative AI tools have no safeguards for children. Parents and schools had no say over what a child generates, what goes online or how long they spend building.
What we did
A kids product with its own frontend and rules: generation restricted to child appropriate content in the backend, games by age band, and a supervising adult in charge of publishing, time and access.
The outcome
Builder Kin went live on its own domain, deployed in the founder's Azure account, and QA completed a full cycle from sign up and family setup to generation, editing and publishing.
- Status
- Live on its own domain
- Built for
- Children, parents and schools
- Parent controls
- Publish approval, time limits, curfew, PIN lock
- QA
- Full cycle, sign up to publishing
The starting point
Builder Kin lets children make websites, games and animations by describing them, while a parent or supervising adult runs the account. It is the kids edition in the founder's family of AI builders, pitched to schools as an organization subscription.
What had to change
Generative AI tools have no safeguards for children. Parents and schools need control over what gets generated, what goes online and how much time is spent.
What could not break
- Nothing goes online without a supervising adult's approval
- Generation stays child appropriate, enforced in the backend
- Age rules apply the same way everywhere in the product
- Kids wording everywhere: credits become parts
- A child's data can be deleted, with consent checked at sign up
The calls we made
We treated child safety as a rule in the backend that generates, not a filter on the screen.
- 01
A product of its own for kids and schools
We proposed a separate kids and education product with parental monitoring and content guardrails, sold to schools at the organization level, with its own frontend, wording and domain. The founder agreed.
Ruled outOne builder for every audience.
- 02
Guardrails where the content is made
Generation is restricted to child appropriate content in the backend, following a written guardrails document, and unsuitable destinations or content categories are blocked there, so no screen can get around it.
Ruled outRelying on limits in the interface alone.
- 03
Ask before building, then match the age
A few short questions shape the theme, content and pictures before anything is built, and games follow the child's age band: pop up games for ages four to six, guessing games for seven to nine.
Ruled outOne output style for every age.
- 04
Parents hold the keys
A supervising adult sets up the family and decides publishing permissions, daily time limits, an evening curfew and a PIN lock similar to guided access on phones. The child builds freely, but nothing goes online without approval.
Ruled outPublishing straight from the child's account.
- 05
Words and pictures made for kids
Credits became parts, and pictures come from the Openverse open image library, matched to the topic with OpenCLIP, so what a child sees fits a child.
Ruled outAdult wording such as credits, and open web image search.
How the system fits together
What we built
Guarded generation
A backend pipeline restricted to child appropriate content. A few questions shape the theme and pictures first, and kid friendly pictures come from Openverse, matched with OpenCLIP.
Play while it builds
The child is greeted by name with starter ideas such as a dinosaur quiz, can type or speak an idea, plays a slide puzzle picked for their age band while the site generates, then sees it live and edits it.
Launch surfaces
A waiting list page, a colorful landing page, verification emails with new templates, a subscription plans screen, a final logo in light and dark, analytics, SEO and a resources and blog section.
Family setup and parent controls
Parent account creation, family setup, publishing permissions, daily time limits with an evening curfew, a PIN lock similar to guided access on phones, an age and consent check at sign up, and deletion of a child's data.
How it works
Describe it
The child is greeted by name and types, speaks or picks an idea, such as a dinosaur quiz.
Answer a few questions
Short questions about favorites and pictures shape the theme, content and visuals, or the child skips them.
Play while it builds
A game picked for the child's age band runs while the site generates.
See it live
The finished site appears for the child to try and edit.
Parent approves
Nothing goes online until the supervising adult approves it.
A closer look
What changed
Builder Kin went live, with a production version on its own domain and the team reporting everything working as expected. QA then completed a full cycle across sign up, family setup, access controls, generation, editing and publishing.
Under the hood
- Datics role
- Product built by Datics
- Safety boundary
- Backend content restrictions, age bands, adult approval before publishing, daily time limits, a curfew and a PIN lock, set out in a written guardrails document.
- Consent and privacy
- An age and consent check at sign up, terms and privacy links, and deletion of a child's data on request.
- Pictures
- Kid friendly pictures come from the Openverse open image library, matched to the topic with OpenCLIP.
- Deployment
- Development and production on separate virtual machines in the founder's Azure account, deployed through a reviewed CI/CD pipeline, with Clarity analytics and SEO in place.
Data and retrieval
Cloud and infrastructure
Apps and APIs
Also in the stack
How it shipped
Proposal
We proposed a kids and education product with parental monitoring and content guardrails, pitched to schools, and the founder agreed.
Waiting list and design
A waiting list page went live to collect emails, with a claymorphism style redesign and a colorful landing page.
Controls and guarded generation
Parental controls and the generate screen were demoed to the founder, then the kids frontend, guarded generation and kid friendly pictures were built and deployed.
Live and tested
A development version went live, production followed on its own domain through a reviewed deployment pipeline, and QA completed a full cycle from sign up to publishing.
Shipped into the founder's own accounts
Code went into the founder's own GitHub organization, and development and production run on virtual machines in his Azure account.
Reviewed before every release
Every change, including the production deployment pipeline, went through pull request review before it reached development or production.
Live demos with the founder
The landing page, parental controls and generate screen were demoed live to the founder, who agreed the direction and the outreach to schools.
What this unlocked
School accounts, where an admin adds students and gives them their sign in, are in testing for a proposed school pilot, with free access in exchange for feedback.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.