The build
My two kids compete in Science Olympiad. I was coaching a 15-kid elementary team and watching the same problem every week: the material is dense, the events are wildly different from each other, and nobody (kids or parents) knows where to start or what to study next.
So I built them something. OlyPrep began as an internal app for my own team, then got forked into a multi-tenant product and rebuilt over about seven weeks. It went live quietly.
Two weeks after the team started using it, they'd run more than 600 practice tests and over 1,000 learning sessions. Then parents and coaches I'd never met started signing up, and ran 200+ sessions of their own. My daughter placed first in her event that season. My son finished fifth overall in a league of roughly 600 kids across 40 teams.
Everything below is the method, not the marketing.
Three product decisions that got it used
Constrain the AI. Don't open it up.
OlyPrep's coach only answers inside the Science Olympiad material. Ask it something off-topic and it pulls you back. That one limit is why parents trusted it with their kids, and why kids stayed on task instead of drifting into an open chatbot.
For your business: a narrow assistant that does one job well gets used. A general “AI for everything” gets abandoned.
Make it adaptive, not static.
The practice engine tracks where a student is weak and sends more of exactly that. Every session is relevant to the kid sitting in front of it, so they come back.
For your business: adoption follows relevance. A tool that reacts to the user beats one that shows everyone the same thing.

Give them a plan, not just a tool.
Kids and parents don't know how to prepare: where to start, what to study, in what order. So OlyPrep hands them a weekly schedule per event, a path through dense material, and a short audio explainer for the hardest topics. They always know what to do next.
For your business: people don't adopt tools they have to figure out alone. Pair the tool with onboarding and a clear next step, so the right way to use it is obvious.

Three engineering decisions that let me ship it fast
Decide the hard things first.
Before any feature code, I wrote a strategy analysis that argued out seven product decisions and the account architecture, then a design brief and a 19-PR engineering plan. Every later step inherited settled decisions instead of re-arguing them mid-build.
For your business: most AI projects thrash because the hard calls get deferred. Deciding first is what buys speed later.
Ship small, reversible, behind flags.
OlyPrep has shipped as 279 pull requests, each one small enough to release and reverse on its own, each hidden behind a feature flag until the whole vertical was finished and tested. “Code shipped” has never meant “feature live.” There are 37 end-to-end test specs guarding the paths a kid actually walks.
For your business: you see steady, low-risk progress every week instead of a six-month black box that either works or doesn't on launch day.
Prove the pattern on two real cases before scaling.
Before building out every event, I shipped two to real kids, collected a week of feedback, locked the pattern, then scaled the rest.
For your business: pilot on a narrow slice, learn from real usage, then roll out. It's the opposite of a launch nobody adopts.
What careful looks like when the AI generates the content
The hardest problem in OlyPrep isn't the app. It's that AI-generated practice questions are confidently wrong often enough to destroy a parent's trust in one sitting.
So no generated question reaches a student on the strength of the model that wrote it. A separate model checks each one against the competition's own rulebook, and a question only becomes servable if it passes. When I tested that validator by seeding ten deliberate errors into a batch, it caught nine of them.
The first run through the legacy question set validated 1,006 questions, rejected 71, and left none uncertain. The production bank holds roughly 3,000 servable questions against a target of 3,340, and a weekly job reports which cells are thin.
Grading moved to the server for the same reason. The answer key is never sent to the browser, papers are recorded as served before they're graded, and one writer owns every table that a score touches. It's the kind of work nobody notices when it's done right.

That workstream shipped 95 pull requests in about eighteen days: the question bank, the validator, server-side grading, a timed test-day mode, a finals board, and a report card that shows a kid what to practise next.
Why this is on an agency site
OlyPrep is my own product, built for my own kids, and it's still under active development. It's here as the honest answer to a fair question: one operator, 279 pull requests, 23 event surfaces across two olympiads, a validation layer between the model and the student, and a product that is still being shipped.
That's the standard I bring to client work.
The build breakdown
The six decisions above, written up as a two-page reference you can take to your own build.
Download the PDF
