Launching a study platform for thirty fields at once

Most teams building a learning product start with the screen a student sees. We started with the shape of a question, and we would do it that way again.

Quizplus now serves more than ten million students and holds a 4.7 rating on the App Store. It launched in 2019 covering thirty fields of study at once, which was either ambitious or reckless depending on the week. This is what that decision forced us to get right first.

The content model is the architecture

A question is not a string with a right answer. In a working platform it is a record with a stem, a set of options, a correct response, an explanation, a difficulty, a source reference, a subject, a chapter, a set of prerequisite concepts, a language and a revision history. Every one of those fields was in the first schema, including the ones we were not yet using.

That sounds like over-engineering. It is the opposite. The cost of adding a field to a table with ten thousand rows is an afternoon. The cost of adding a field that has to be populated retroactively across millions of rows, by people, for content that has already been sold to students, is a quarter of work and an argument about whether it is worth it. Fields that describe what a thing is, rather than how it is displayed, should be decided before volume arrives.

Thirty fields of study at once also forced a discipline that a single-subject launch would have let us dodge. Nothing subject-specific could be hard-coded. A chemistry question and an accounting question had to be the same kind of object, differing only in data. The moment we allowed one subject a special table, every subject would eventually have wanted one.

The second decision was to separate the content pipeline from the product. Authoring, review, correction and publishing are their own system with their own permissions and their own audit trail. Students see a published snapshot. Editors work on drafts. When a student reports that an explanation is wrong, the correction has a reviewer and a date, and we can say what changed and when.

Search is what makes content exist

A student does not browse a chapter tree. They type a fragment of a question they are looking at and expect the right item back. If search fails, the content is not there as far as the user is concerned, no matter how much of it you have.

Two things made this harder than a normal product search. Questions are long and similar to each other, so ordinary relevance scoring returns a page of near-identical items. And students paste text with typos, broken line breaks, half a sentence, or the numbers from their own version of the problem.

What worked was fairly boring. Index the stem separately from the options and weight it higher. Fold the numbers out of a query when matching, because the numbers are usually the part that differs between two versions of the same problem. Deduplicate aggressively at index time rather than at query time. And measure the result with real queries from real logs, not with a test set someone wrote by hand.

Billing on day one, not after product-market fit

Subscriptions, cancellations, refunds, proration and failed payments were in the first release. This is the single decision from 2019 we would most strongly defend.

Retrofitting billing is where consumer products lose months, and the reason is not the payment integration. It is that money creates state that the rest of the system has to respect. Who has access to what, and until when. What happens to that access when a card fails on the third of the month. What a refund means for content already consumed. What a downgrade does mid-period. Each of those is a rule that has to exist in one place, and if it is added late it ends up scattered across a dozen conditionals in the application.

The other reason is evidential. From the first day, a customer who wrote in about a charge could be answered from a record: what was charged, when, against which plan, with what outcome. Consumer support without that is guesswork.

That work is the direct ancestor of Churn Solution, now a Stripe partner. We built it because we had been running the manual version of it for years across the platforms we operated.

What a consumer product costs that an enterprise one does not

Running a platform for millions of students taught us costs that no internal system ever charges you.

Support volume scales with users and never stops. A one per cent contact rate at ten million users is not a small number, and most of those contacts are about billing or access rather than the subject matter.

Abuse is constant. Shared accounts, scraped content, bulk sign-ups, card testing against the checkout. Every one of those needs a detection rule and a response that does not lock out legitimate students.

App store release cycles set a floor on how fast you can fix a native bug, which is why anything that might need an urgent change has to be server-controlled.

And content liability is real. A wrong answer in a published explanation is not a cosmetic defect to the student who relied on it in an exam. That is why the correction path has a service level of its own.

What carried over to government work

Three things, and they are the reason we talk about this product in public-sector proposals at all.

The first is designing for the operator rather than the end user. A platform at that size cannot be run by the team that built it looking at raw logs. It needs dashboards that answer specific operational questions, logs that a person can search by user and by time, feature flags that turn a broken thing off without a deploy, and releases that can be rolled back. A department inherits exactly the same needs on the day the vendor leaves.

The second is that peak load is a product requirement, not an infrastructure detail. A study platform the night before exams and a citizen portal on a tax deadline are the same shape of problem.

The third is the separation between authored content and published content, with a review step and an audit trail in between. Replace question with regulation, form or fee schedule and you have the change-control model a public body already needs and often does not have.

Where we would push back

This sequence is not right for every project.

If you do not yet know what the content is, building the content model first will simply encode your first guess and make it expensive to leave. We were able to start from structure because thirty syllabuses already existed in the world and we were modelling something real. When the domain is genuinely unsettled, model less and stay loose for longer.

Billing on day one is also specific advice, not a universal law. It applies when you know you are selling subscriptions. If the commercial model is undecided, the equivalent discipline is to keep every access decision behind one entitlement check, so that whatever you eventually sell has somewhere to plug in.

And launching across thirty fields cost us depth. For the first year, each subject was thinner than a specialist competitor. We accepted that trade deliberately. The question worth asking before copying it is whether your users compare you against a specialist or against having nothing.