The weight of who you are building for

Every piece of software carries an implicit assumption about its users. Enterprise B2B software assumes users who will tolerate learning curves, who have IT support, who operate within predictable working hours, and who will not be harmed by a slow response time. Consumer software assumes users who can choose whether to engage and walk away when it frustrates them. Student software carries a different assumption entirely: users who are under pressure, who may not have chosen the tool voluntarily, who are often alone when they use it, and who may be in genuine distress.

VarsityOS was built for South African students preparing for university examinations. It uses spaced repetition, AI tutoring, past paper analysis, and progress tracking to improve study outcomes. But the decision that shaped its architecture more than any other was not about learning science or AI capability. It was about what happens when a student using the platform is not okay.

The problem with third-party dependency at the critical moment

The naive implementation of crisis detection in an AI product is to route the user message to the AI model and ask it to evaluate the content for distress signals. This is how most products handle the problem when they handle it at all. The AI is already in the loop. It seems obvious to use it for this too.

The problem is that this approach fails at exactly the moments it most needs to succeed. AI providers have outages. APIs return 529 errors. Rate limits are hit. Network connections drop. At 2 AM, when a student who has failed an important test for the third time sends a message that should be caught by a crisis detection system, the last acceptable failure mode is "the API was unavailable."

A system that routes crisis detection through a third-party API is a system that delegates its duty of care to a company that has no knowledge of the individual user and no obligation to respond in any particular timeframe. This is not a risk worth accepting.

Local pattern-matching, first

VarsityOS crisis detection layer runs entirely locally, before any external call. It is a pattern matcher: a curated set of phrases, linguistic structures, and semantic signals that indicate distress, loaded into memory at startup and evaluated against every message in under 2 milliseconds. The patterns were developed carefully and are reviewed regularly. They catch explicit statements of distress, indirect expressions of hopelessness, and phrases that correlate with crisis in student populations specifically.

If a message matches a crisis pattern, the system responds immediately with an appropriate intervention, logs the event, and does not proceed to the AI model for a general response. The entire flow completes before any external API call is initiated. The system works if Anthropic is down. It works if the user data connection drops after the message is sent. It works at 2 AM on a Saturday when nobody is monitoring the infrastructure.

Only messages that pass the local crisis screen proceed to the AI model for tutoring, analysis, or general conversation. This is not a performance optimisation. It is a sequencing decision: the safety check happens first, always, without exception.

Spaced repetition, built from scratch

The other architectural decision that defined VarsityOS was the choice to implement the SM-2 spaced repetition algorithm in-house rather than using a third-party library or service. This decision was less urgent than the crisis detection one, but it reflects the same underlying principle: ownership of the critical path.

Spaced repetition is the learning mechanism that makes VarsityOS genuinely effective rather than merely engaging. The SM-2 algorithm tracks each student performance on each piece of content, calculates the optimal review interval, and schedules items so that the student reviews them just before they would forget them. A student who uses a well-implemented spaced repetition system consistently retains significantly more than one who uses passive re-reading or self-directed revision.

The decision to build SM-2 in-house rather than licence it from a third party meant writing approximately 200 lines of deterministic TypeScript that we fully understand, own, and can debug. It means our review scheduling logic is not dependent on a service that might change its API, increase its pricing, or shut down. It means when a student study pattern behaves unexpectedly, we can read the source code and understand exactly what is happening.

What 130 live users actually means

VarsityOS has 130 active users at the time of writing. This number is small relative to the platforms VarsityOS is competing with. It is not small relative to what it represents: 130 students in South Africa who are studying differently because this system exists, whose distress signals will be caught before the AI model sees them, whose review schedules are calculated correctly without a third-party library, and who are building genuine retention rather than the illusion of it.

Software for education in African contexts rarely gets built to the standard it deserves. The market is considered difficult. The users are considered less lucrative than enterprise clients. The duty of care is considered someone else problem, typically a mental health resource hotline bolted on as an afterthought. VarsityOS was built from the assumption that the opposite is true: that the users who most need good software are the ones who receive the worst of it, and that the gap between what they receive and what they deserve is an engineering problem with an engineering solution.

The solution begins with sequencing. Safety first. Model second. Never invert this order.