MENTR
Full-stack LMS and e-commerce platform serving 10K+ monthly users for MDCAT preparation across Pakistan.
The problem
Pakistan's MDCAT prep market is one of the highest-stakes academic verticals in the country — a single annual test determines medical school admission for tens of thousands of students. The existing digital options were old PHP-era platforms with slow page loads, no real-time feedback, and no integrated way to actually purchase the course.
MENTR needed to launch a credible alternative: a platform that loaded instantly on the cheap Android phones most students use, ran timed mock tests under real exam pressure, and let users go from landing page to enrolled student in under two minutes.
The approach
I architected and shipped the platform end-to-end. The brief was simple — fast, reliable, and ship-able by the next admission cycle. The constraints drove every decision: Next.js for SSR-by-default so first paint stays under a second on 3G, PostgreSQL for the relational data (courses, enrollments, attempts, payments) because we needed real joins and transactions, and Redis aggressively for sessions, leaderboards, and the question bank to keep the database off the hot path.
The quiz engine was the technically interesting part. Students take timed mock tests with thousands of concurrent attempts during peak hours. Scores have to be reconciled instantly across geographic and academic dimensions for live leaderboards. I built it as a write-through cache layer over PostgreSQL — Redis holds the active attempt state and leaderboard ZSETs, Postgres is the source of truth for completed attempts and analytics.
On the commerce side, payment integration was wired directly into enrollment. There's no separate checkout flow — purchasing a course IS the enrollment action, and access flips on via webhook reconciliation, not optimistic UI.
Stack & decisions
Most students browse on entry-level Android. SSR + edge caching gives them HTML in 700ms; a client-rendered SPA was hitting 4–5s on the same devices.
Course → enrollment → attempt → payment is fundamentally relational with strict consistency requirements. Postgres for state, Redis for speed.
Payment webhooks reconcile against pending enrollments. No optimistic UI on money flows — access only flips on after the gateway confirms.
Per-region, per-subject, per-test leaderboards all served from sorted sets. Recomputes on attempt submission, reads in single-digit ms.
Outcomes
What I learned
The biggest unlock wasn't a clever algorithm — it was being aggressive about what doesn't need to hit the database. Redis-backed sessions and pre-warmed question pools shaved more milliseconds than any query optimization. Cache invalidation is hard, but cache-first design is easy.
Building solo across the stack forces you to feel every decision twice: once when you make it, again when you have to operate it. That feedback loop made me default to boring, proven tooling — Postgres over the latest, server actions over a separate API, the platform features Next gives you instead of inventing parallel systems.