Case study — Starlite Learning
An AI learning platform that rebuilds every lesson around what a child already loves.
An adult sets the curriculum boundary; every lesson inside it is rebuilt around what the student already cares about, so the subject arrives in a story they were going to pay attention to anyway.
- Beta size
- 50+ families in the private beta
- Team
- Solo designed, built, and shipped with Claude Code
- Timeline
- 9 months hypothesis to web, iOS, and Android
What Starlite is
Starlite is an AI learning platform for elementary students. Students learn their topics through Starlo, their AI tutor, and practice through activities and games, all tailored to their personal interests.
Behind that, a parent or teacher defines the topics their student will study, and every topic is assessed before and after so learning can be measured and documented.
Four components make it work:
- Classes
- set the boundary. An adult defines the topics, and the AI teaches nothing outside them.
- Lessons
- are rebuilt inside that boundary around the student's interests.
- Activities and games
- are generated within lessons to keep students engaged.
- Progress
- is proven by an assessment before and after every topic.
None of that structure was obvious at the start. The product arrived there because of what research forced.
The hypothesis
Most educational software delivers the same lesson, the same examples, and the same pace to every student. Meanwhile one child is captivated by Minecraft, another by dinosaurs, another by space exploration, and none of that gets used.
That gap produced a single testable claim, and everything else in this case study exists to serve or verify it:
If a lesson rebuilt itself around what a specific child already loves, engagement would rise, and learning outcomes would follow.
In practice that means fractions become a Minecraft resource problem and reading practice becomes about dinosaurs. The same objective, taught through something the student already cares about.
The claim has two halves, deliberately. Engagement was the intuitive part. Outcomes were the part that mattered, and the part I would need evidence for, which is why measurement ended up built into the product rather than added afterward.
I began with homeschool families because they select their own curriculum and purchase independently, which let me test both halves and willingness to pay in a single motion. Before writing any code, I put the claim in front of them.
Research redirected the product: the hard problem wasn't teaching, it was trust
I surveyed 54 homeschool parents. Demand was real: 54% named interest-based teaching as their single top reason to use it, and 69% used nothing comparable today.
The resistance was more specific than I expected. Almost nobody rejected AI outright: only 9% were uncomfortable with a student-safe AI teaching their child. But almost nobody accepted it unconditionally either. The largest group, 48%, was comfortable given oversight, and 35% expected to approve every topic themselves.
Comfort was conditional. So the question was never whether parents would allow an AI tutor, it was what they required in order to, and when asked what worried them they named the same thing over and over.
“Accuracy of information provided by the AI.” Survey respondent
That reframed the build. Adoption wasn't gated on a smarter tutor. It was gated on a verifiable one: accurate enough to be trusted with a lesson, and bounded enough that a parent stayed in control of what got taught.
Further detail from the survey 4 findings
- 91% likely or very likely to try it (69% very likely)
- 87% rated interest-based personalization “very valuable”
- Engagement was parents' most-cited struggle overall, the exact problem personalization targets
- Roughly 4 in 5 named a price rather than holding out for free, clustering at $10–20 per child per month; 13% already spend more on curriculum today
Every decision after that traced back to a finding:
| Research finding | Product decision |
|---|---|
| 54% want interest-based teaching | Interest-driven lesson generation |
| Accuracy is the top objection | Hybrid validation and a deliberate cost tradeoff |
| 35% want to approve every topic | Adult-defined classes; AI locked to them |
| Parents need year-end proof | Assessments feeding a compiled portfolio |
Two users who want opposite things
The trust finding created a design problem. A seven-year-old wants delight, momentum, and zero administration. The adult on the other side, a homeschool parent today and a classroom teacher next, wants control, visibility, and evidence.
Adult control should be fully felt by the adult and completely invisible to the child.
A student should never hit a wall that reads as “your mom blocked this.” The boundary should just feel like the shape of the class.
The adult side is an operations hub, not a settings page
Homeschool parents aren't casual users. They are administrators running a school year and they already have a system, so the dashboard is organized around three jobs.
- Define the boundary
- In the curriculum builder, an adult types in their own learning topics or pulls prebuilt ones by grade level, and can author custom activity modules from text, video, and images. Setting the AI's limits had to feel like curriculum planning, not software configuration.
- Run the week
- The calendar schedules it; the work hub captures everything else. Parents log learning that happens outside Starlite, photographing finished worksheets or recording work from other curricula, and the AI folds it into the same record. No family runs their whole year on one tool, so competing to be the entire curriculum was the wrong fight. Being the system of record for all of it was the better one.
- Prove it happened
- A portfolio the AI compiles from both sources, built against year-end evaluation requirements rather than engagement metrics.
The permission model ships with parent, teacher, and district roles even though the beta only needed the first. Designing that hierarchy up front means district expansion is an unlock, not a rebuild.
Where that oversight stops The tradeoff
One thing the dashboard deliberately doesn't show is the conversation itself. Parents can't read back their child's tutoring sessions, because storing every exchange across every student was an infrastructure cost I chose not to carry yet.
That removes the most literal form of oversight a parent might expect, so oversight had to come from structure instead of surveillance. Adults control the boundary the conversation happens inside, see the objective it targeted, and see the scores on either side of it. Not what was said, but what was covered and what stuck. It's the compromise I would revisit first.
The student side hides all of it
What the student gets is a conversation and things to do. No topic list, no settings, no sense that a boundary exists. The class an adult spent twenty minutes building shows up to the child as Starlo wanting to talk about fractions using Minecraft.
How a topic runs
Every topic moves through the same six steps, from an adult setting it up to a report landing back with them.
- Pre-quiz. What the student already knows. The “before” half of the measure.
- Star Challenge. A themed activity built around the objective, like an escape room, that the student cannot beat yet.
- Tutoring. They learn the objective in conversation, practicing on small generated activities along the way.
- Beat the challenge. They return and complete it, applying what they learned.
- Final quiz. What stuck. The “after” half.
- Report. Scores and completion roll into the adult's portfolio.
The Star Challenge is the spine. A learning objective is a weak motivator on its own: “today you will learn to compare fractions” gives a student nothing to want. So the lesson opens with something they want to beat and cannot yet, which reframes the objective as the means rather than the goal. Learn this so you can beat the thing.
Open-ended AI vs. the structure a classroom needs
Chat and generation are open-ended by nature. Education needs boundaries, sequence, and something an adult can trust. That tension showed up twice.
The conversation
An unrestricted conversational tutor. It worked technically and failed educationally. Students drifted off-topic and parents lost confidence.
Adult-managed classes. They define the exact topics; the AI stays locked to them. Open interaction, inside a boundary someone else draws.
The activities
A fixed menu of activity types. It worked, but it capped the promise. A fixed set runs out, children start seeing the same shapes, and “never runs out” dies.
Stop generating whole activities, generate from parts. ~50 composable, validated block types the AI assembles into larger templates tied to the lesson and the student's interest.
Constrain the pieces, free the composition.
Every block is checkable, so activities stay valid. But across 50 primitives and any interest, the combinations feel limitless.
Accuracy you can put in front of a child
A chatbot being wrong is annoying. A tutor being wrong teaches the wrong thing and burns the trust the product depends on.
Hardcoded validation, so every generated answer had to actually compute before a student saw it. That held for math and broke as topics expanded. You can't write a deterministic rule for every subject a curious child wanders into.
A hybrid. Hardcoded checks where a domain allows a hard rule, and a more capable, more expensive model everywhere else.
That traded margin for reliability, and I took the cost on purpose. Accuracy was already the top objection gating adoption, so paying for it bought that objection down. An inaccurate tutor isn't a cheaper product. It's a broken one.
Built AI-native, which is why it exists
GPT for the learning layer, Claude Code for development, Node.js on the backend, React Native shipping one codebase to all three platforms.
The method is the point. It's how one person went from hypothesis to a working cross-platform product in the hands of real families in nine months, with design and engineering decisions evolving together instead of across a handoff.
Outcomes
Measurement is built into the product, not bolted on. The same assessments that give parents a record give me a clean read on whether a student actually learned.
Across 10 new topics. A 55-point jump, but on its own that only proves the lessons taught something.
Against a small cohort on a competing digital curriculum, on final quizzes — and the comparison group took roughly 30% longer to finish comparable lessons.
Small, self-selected cohorts, not a randomized trial. The two groups used different curricula and different assessments, so this is a directional signal rather than a controlled result. Still open: does the gap hold across more subjects, and does it survive older grades where exam pressure matters more than intrinsic interest?
What's next
Homeschool stays the near-term focus. The larger opportunity is K–12 districts, and the teacher and district roles are already built, so the constraint isn't engineering. It's evidence.
Districts don't buy on promise, they buy on proof. So: pilot in a handful of districts, measure what the beta already measures, turn those results into district case studies, and expand one at a time.
What I took from it
-
Adoption hinges on trust you can verify.
Parents didn't reject AI, they rejected uncertainty. The hardest design work wasn't generating content. It was earning the right to be left alone with a child.
-
Strategy starts before design.
Research didn't confirm my idea, it redirected it.
-
Building changes how you design.
Owning strategy, design, and engineering meant every decision balanced user need, technical limit, and unit economics in the same moment.