Building Tafawaq: an exam platform that had to feel like the real test

Tafawaq prepares students in Saudi Arabia for Qudrat and Tahsili, the national tests that shape where they study and what they study. Sixteen thousand students registered in the first year. The apps built on the same engine hold a 4.7 rating on the App Store. Those numbers are the outcome of one decision made early, which was to treat fidelity to the real examination as the product requirement, and everything else as secondary.

That sounds obvious. It is not how most exam preparation software is built. The usual instinct is to make practice friendlier than the test: generous timing, hints, an encouraging tone, a score that goes up. All of that produces a student who performs well in the app and badly in the hall, and who then, correctly, stops trusting the app.

Fidelity means the uncomfortable parts too

A national test is a specific experience. The sections come in a fixed order. Each has its own duration. You cannot return to a section once it closes. The clock does not pause because you looked away. Questions appear in formats that have their own conventions, and some of those conventions are unintuitive the first time a student meets them.

We reproduced all of that, including the parts that make practice unpleasant. A simulated section ends when its timer ends, mid-question if that is where the student is. There is no pause button in simulation mode. Navigation between sections follows the real rules, not convenient ones. The first time a student runs a full simulation, the experience is often worse than they expected. That is the point. It is much better for that to happen in their bedroom in March than in the examination hall.

The one place we deviate is after the test. A real test gives a student a score. Our simulation gives a score plus a full review: every question, what they answered, what the answer is, how long they spent, and where they lost time. The value of a practice test is entirely in the review, and a platform that shows a score and nothing else has wasted the student's three hours.

One rule set, three platforms

Tafawaq runs on web, iOS and Android. The engineering decision that mattered most was that the examination rules live in one place and are not reimplemented per platform.

The reason is not efficiency. It is correctness. Timing rules, section transitions, scoring, eligibility for a question to appear, all of that is logic where a small discrepancy is invisible in testing and fatal in trust. If the Android build allows a student to return to a closed section because someone implemented navigation slightly differently, then two students practising together get different experiences, they discover it, and the platform's central claim is gone.

So the rules are defined once, server-side, and each client renders them. Clients are responsible for presentation, input and offline resilience. They are not responsible for deciding when a section ends. When a rule changes, it changes once, and it changes everywhere on the same day.

This has a cost, and we should be honest about it. Server-authoritative timing means connectivity matters. A student on a weak mobile connection in the middle of a simulation cannot be told their test is void. So the clients hold enough state to continue a section locally and reconcile when the connection returns, with the server as the authority on the final result. Building that reconciliation properly took longer than building the timing engine itself. It is the sort of work that never appears in a feature list and is the reason the product works on real networks.

Adaptive, but never opaque

The study plan adapts to the student. That is table stakes now, and it is also where most platforms lose people.

The failure is opacity. A system tells a student to spend this week on quantitative comparisons. The student has no idea why. Maybe the model is right. Maybe it is responding to one bad session on a day they were tired. Either way the student has been asked to take instruction from something that will not explain itself, and teenagers are not inclined to do that. Neither are their parents, who are often the ones paying.

So every recommendation carries its evidence. When the plan says to work on a topic, it shows the attempts that produced that conclusion: which questions, when, how long, and what the pattern was. A student can look at it and agree, or look at it and say that was the week of my brother's wedding and I was not concentrating. We let them say that. They can down-weight a session, and the plan responds.

Letting students override the model is uncomfortable for anyone who believes the model knows better. On aggregate, the model probably does. But a plan a student follows is worth more than a better plan a student ignores, and the ability to disagree with the system is what makes the rest of its advice credible.

We also chose not to adapt the difficulty during a simulation. Practice sessions adapt. Full simulations do not, because a simulation that adjusts to keep the student comfortable is no longer a measurement of where they stand. Mixing the two is the most common design error we see in this category.

What we refused to build

We were asked for a leaderboard more than once. We did not build a public one. Ranking students by score against their peers is excellent for engagement metrics and bad for the students in the bottom half, who are precisely the students who most need to keep practising. Comparison is available against the student's own history and against the score bands they need for their target, which is the comparison that actually helps.

We were asked for streaks and daily pressure mechanics. We kept these minimal. A student preparing for a national exam already has more pressure than a notification can usefully add, and a study plan built on guilt collapses the first week it is broken.

We also declined to promise score predictions with false precision. The platform shows a student where they are relative to the bands they need, with an honest range. Telling a seventeen-year-old they will score a specific number is a claim no preparation platform can support, and the ones that make it are borrowing credibility they will have to repay in August.

What transfers to a government assessment system

Most of this is not specific to exam preparation. Any system that measures a person and produces a consequence faces the same three problems.

The first is fidelity between practice and the real thing. If a licensing authority provides a sample test that behaves differently from the actual test, it has created a complaint channel. The sample should be generated from the same rules engine as the real assessment, not maintained separately.

The second is explainability of any adaptive or automated judgement. If a system decides something about a citizen based on their performance, the citizen must be able to see what produced that decision, in their own language, on the screen where the decision appears. Not on request, not via a support ticket. On the screen.

The third is the review, not the result. A result tells a person where they stand. A review tells them what to do next, and it is the thing that makes the system feel like it is on their side.

If you are evaluating an assessment platform, the test we would run at acceptance is this. Take one candidate account. Run a full timed assessment on each supported platform, web and both mobile operating systems, and compare the three experiences question by question and second by second. Then deliberately drop the network mid-assessment on the mobile client, restore it, and check what happened to the elapsed time and the submitted answers. Whatever the proposal says about accuracy or content volume, that half day of testing tells you whether the system was built once or three times.