Offline-first without split-brain state
Allowing practice to continue offline means every write can conflict on reconnect. Defining a clear sync contract — what is authoritative, what merges, what discards — was the central design problem.
Interactive mathematics learning with AI-assisted practice.
Independent product. Publicly available as a live PWA.

01
Mathematics practice tools often assume constant connectivity, rigid curricula and passive content consumption. Learners on unreliable networks lose progress, and teachers cannot see where understanding actually breaks down.
The product problem was to make practice feel immediate and adaptive while tolerating the connectivity reality of the environments it is used in.
02
An independent Polymath product, designed, built and shipped as a public PWA rather than a client engagement or academic exercise.
The goal was a real product with real users — not a demo — so offline behaviour, performance and simple onboarding were treated as core requirements.
03
04
A Progressive Web App that installs like a native app, loads fast and keeps core practice available offline.
An adaptive practice loop with dashboards and leaderboards that give learners feedback without requiring a teacher in the loop for every session.
AI and OCR features that reduce friction when getting problems into the system — while keeping the critical practice path independent of heavy model calls.
05



06
07
Shipped as a PWA at mathquest.tech so distribution does not depend on app stores, and so the same URL works across phone and desktop.
Offline-first architecture: local persistence for in-progress practice, with reconciliation against the server when connectivity returns.
AI and OCR are used at the edges of the loop (intake and assistance) rather than on the critical practice path, keeping the product responsive on weak devices and networks.
Progress, streaks and leaderboards are designed as first-class product surfaces — motivation is part of the system, not a bolt-on.
08 / Hard parts
Allowing practice to continue offline means every write can conflict on reconnect. Defining a clear sync contract — what is authoritative, what merges, what discards — was the central design problem.
Model latency and cost make it dangerous to gate core practice on AI calls. The architecture keeps the practice loop local and treats AI/OCR as enrichment, so the product still works when those services are slow or unavailable.
Education users abandon slow tools. Perceived performance — instant feedback, no full-page reloads, optimistic UI — was engineered deliberately rather than left to framework defaults.
09
MathQuest is live as a public PWA at mathquest.tech. It demonstrates a complete product loop: account creation, adaptive practice, progress dashboards and leaderboards, with offline-capable architecture. Ongoing work focuses on content depth and measured learning outcomes over time.
mathquest.tech
10
Evidence
Live
mathquest.tech
Demo
Product screenshots and mockups
Case study
Architecture and product decisions
Technology
Start a project
If this kind of system is close to your problem, tell us what you are trying to ship.