Building Flip Education's curriculum engine

Why this matters now

AI can now write a large body of data that a product stands on, the kind of work that once needed a specialist team. So writing the data is cheap, and the work moves to proving it is right, because everything downstream stands on it and a mistake in the data shows up everywhere at once. Our data was each country's curriculum in its own language, one tree per country. Country, then subject, then school year, then unit, then topic. The curriculum stopped being an input and became the data layer of the product. The public topic pages stand on it, the other public data pages are built from it, and the product's own quality check stands on it, because that check tests that every lesson matches the curriculum it was planned for.

The challenge

Teachers only care about the curriculum of their own country. So in every country we served, a teacher would only use the product if it followed that country's own curriculum, which meant each country's curriculum had to be in the product as data. That meant 11 languages, every subject and every school year. National curricula are public and relatively well maintained, which gave us something solid to check our data against. We had no curriculum team, just the two founders and the AI agents. Our first bet was that every AI model already knows these curricula and could write them from memory. It clearly didn't work.

How the engine works

First, AI models wrote each country's curriculum subject by subject and year by year, in the country's own language, so the data for every country existed within days, work that would have needed a specialist team. A script, with no AI, rejected any data file with the wrong shape, so bad data failed early. Then we tested several AI models head to head on quality, speed and cost, and the one picked split every subject into lesson-sized topics, so a user could plan a lesson on one small topic.

After that, we compared the data with the subject names each ministry publishes and with lists of every subject a country's curriculum requires, in a check for missing subjects across all 18 countries. I didn't trust a count of likely gaps until a sample had been checked, and I had every gap we found fixed, without first testing whether anyone asked for it. Gaps were now looked for country by country, where before they had turned up one user at a time.

What the checks missed still surfaced. Users' searches that found nothing, and what teachers told us, showed the gaps. My co-founder and I checked the data, and so did the teachers in the pilots and teachers outside the pilot. Each gap went back into the data, round after round. Later, an independent AI judge, a separate model reading blind, passed a page only if it could be published as written. Work that judge fails never reaches the live site.

Splitting subjects into topics

Once the data existed, each subject had to be split into topics small enough for one lesson. I would say a user doesn't necessarily plan a lesson on all of DNA. They can plan one small topic, part of a unit, for one class, and the product had to allow exactly that. That meant building a taxonomy, a fixed structure for sorting topics, and splitting each subject into it. The first decision was how big a topic should be. My co-founder argued for about 60 topics per subject and school year, because that's roughly how many lessons a teacher gives in one school year, so the rule became one topic is one lesson, one specific event, concept or skill, never a multi-week unit. Units follow the school calendar rather than textbook chapters, because every school has a calendar while chapters differ from book to book, and each topic is tagged with its unit. We ended up with 40 to 60 topics per subject and school year, and each topic got its own public page.

Matching a user's own words

The homepage has one search bar. A user types what they want to teach, and simple rules find the subject and school year in those words. Then an AI model picks one existing topic and a teaching method, and it could answer "no match" instead of forcing a guess.

The curriculum pages have their own search box. In May, about 29% of searches in that box found nothing. We rewrote the matching and added new subjects, and afterwards about 5% found nothing.

The lesson page has a separate topic search with no AI. When I looked at its early misses, about a third were topics the product had in the same subject but in another school year. Almost half were topics it had somewhere, in another school year or another subject. One pilot teacher searched for circles in one school year, where we didn't have them, and the topic sat in the next year. And that circles miss started the work on a smarter topic search, one that tolerates typos and searches unit names and key questions too, and that version shipped.

What the search chart shows

All 18 countries went live in February. That week the curriculum pages had about 2,500 impressions in Google search. An impression is one time a page appeared in Google's results. The next week brought about 27,000. They then held around 20,000 a week until late March. After the subjects were split into lesson-sized topics and the objectives and vocabulary were added, the numbers rose sharply. By May they had settled at about 200,000 a week. The chart below shows these weekly impressions.

What it would have cost with people

We estimated the same data built by people, using Spanish pay for curriculum and e-learning designers and assumed times per topic. It comes to about EUR 0.8 to 2.2 million. That's a specialist team of about 13 people. They would work for about 2.5 to 6 years. The estimate covers a lean version, the same countries and topics with objectives, vocabulary, assessment ideas, subject mapping and a gap check. It would have been prohibitively expensive, and this project wouldn't have been possible without AI.

What I would keep, what I would change

I would keep the checks, and the habit of fixing every gap users found. I would change the start. The call I got wrong was the first bet. We should have started from the official lists of each country's standards on day one, instead of the model's memory.

Advice for the team building this

If your team builds a public dataset with AI, a founder early on or a data team in a bigger company, assume the model's memory is wrong and design the checking first. Decide what the data is checked against, who checks it, and what happens when a check fails. If you can afford it, I would also hire a specialist early on to sample the data and look for mistakes. Then keep correcting. Users will find gaps you missed. It took us several rounds.