Brilliance.

What production actually holds

The platform cut over to its own production stack in June 2026, carrying exam history from the pilot back to June 2025. It is not a demo: in the 30 days to 12 September 2026 it recorded 26,183 exam submissions from 3,961 distinct students, 8,287 of them in the last week alone, and the busiest single day so far moved 2,673 submissions. Alongside that sit 34,636 exams, 82,205 attendance records, 82,847 homework attempts, 20,060 assignments, 24,856 student doubts with 67,477 follow-ups, and 4.28M notifications dispatched. The database is 14 GB across 323 tables.

Some subsystems are worth calling out by volume, because they are the parts people assume software cannot do: 12,672 OMR sheets scanned and matched to students, 1,085 handwritten answer sheets graded by AI with 12,847 per-question marks reviewed by faculty, 3,020 locked-down kiosk devices in exam halls, and 1,274,538 exam-integrity events recorded.

The problem

Indian junior colleges that prepare students for JEE / NEET / CLAT / IPMAT run on a stack of disconnected tools. Attendance is on one SaaS, assessments on another, student communication is over WhatsApp, parents get nothing. Branch admins manage spreadsheets. Faculty draft questions in Word. Students write tests on printed paper, get scores three days later, and learn nothing about the wrong answers. The loop the whole model depends on, practice to feedback to practice, runs at days of latency when it needs to run at minutes.

Brilliance consolidates that loop into one platform: four user types (super admin, branch admin, faculty, student, parent), web and native surfaces, AI-generated questions with a faculty gate, and an analytics layer that tells every actor what changed since yesterday. It has to feel light enough for a 16-year-old on a 4G connection between classes, and structured enough that a branch admin trusts the attendance report at the end of a quarter.

Market & opportunity

India's competitive-exam machine is enormous: the coaching-institutes market is ~$7.2B and compounding ~10% a year[1], feeding a funnel of ~3.8 million JEE + NEET aspirants annually (22.76 lakh for NEET 2025 alone)[2][3], before CLAT, IPMAT, CUET and state CETs. The category just went through a violent correction: BYJU'S collapsed from a ~$22B valuation to insolvency[5], and the survivor playbook, Physics Wallah's disciplined hybrid model, was validated by a ~$3.8B IPO in November 2025[4].

Two forces define the opportunity. Post-BYJU'S, D2C customer-acquisition burn is dead, and the market now rewards infrastructure and unit economics. Second, the Ministry of Education's 2024 coaching-centre rules bar enrolment under age 16, pushing the market toward the 16+ junior-college (Class 11 to 12) segment Brilliance serves[6], a regulatory tailwind for a B2B-to-colleges play.

The student mix in production tracks that funnel exactly: 3,489 students targeting JEE Mains, 551 NEET, 547 the Andhra/Telangana EAPCET, 112 IPMAT Indore, plus CLAT and JEE Advanced cohorts.

What I built

The repo is a Turborepo + pnpm monorepo: 13 apps (8 Next.js 15 web apps, 5 Expo SDK 55 native apps) and 55 shared packages, 6,826 TypeScript files and roughly 1.8M lines. My work concentrates in six areas.

• Admissions CRM with an AI voice agent (125 merged PRs). The largest single thing I have built here: ~220k lines across the CRM web app, its API, its voice service and a counsellor companion app. An AI assistant calls a new enquiry within five minutes, follows a five-step script, scores the call, and writes it up; counsellors can take coached calls on their own handset, with LiveKit egress keeping the audio and a per-speaker transcript. Campaigns go out over SMS (Twilio or Plivo) and WhatsApp Cloud API with consent gates, unsubscribe and receipts. A knowledge graph links repeat enquiries, both parents and siblings into one family. It runs on staging today, not yet in production.
• IPE: grading handwritten answer sheets (112 merged PRs). Faculty upload scanned board-exam answer papers; the pipeline identifies the student, extracts question regions and handwriting with OCR, proposes marks against a rubric, and pins them beside the answers on the sheet itself. Faculty stay the deciders: every mark is editable on a review desk with the question paper and answer key side by side, results are released explicitly, and revaluation is first-class. 1,085 sheets and 12,847 marks have gone through it in production.
• The student surface (69 merged PRs). Test runner, results, subject-wise ranks, error analysis and the remediation loop that turns a wrong answer into a scheduled revision question. I am the top contributor to apps/student.
• Assignments and homework (104 merged PRs between them). Timetable-driven homework generation, a review surface for faculty, the student calendar, telemetry on what was actually attempted, and fixes to the parts that silently corrupt trust: answer keys that name an option rather than an index, never re-serving a question a student has already seen, and shuffling options when a key turns out lopsided.
• Question pipeline (64 merged PRs). Generation, validation and the v7 extractor that pulls questions, figures and solutions out of PDF papers, including the region-crop fallback that stopped figures from vanishing.
• Exam integrity and the schema (top contributor to packages/db). Sealed papers use envelope encryption: the paper payload is encrypted with a data key wrapped by AWS KMS and released only at exam start. 216 migrations, 323 tables in production.

I also wrote the CI guard that keeps internal detail off student and faculty screens. It exists because a raw provider error once shipped to faculty verbatim: a 402 telling them to go top up an OpenRouter account. Every error that can reach a screen now passes through one scrubbing function, and check-error-leaks fails the build if a raw error is written into a user-facing field.

Architecture

One Hono API, 152 route modules

The backend is a single Hono service with 152 route modules, hosted in AWS Mumbai on ECS Fargate (two API tasks, four workers) behind an ALB. Persistence is Drizzle ORM over PostgreSQL on an m7g.xlarge RDS instance with a read replica; Redis fronts hot paths and backs BullMQ for everything deferrable: grading cascades, notification fanout, extraction jobs, reminder runs. Shared domain logic is migrating onto Effect v3, package by package, with the typed-error and retry discipline that brings.

Thirteen apps, one type system

Eight Next.js 15 / React 19 web apps (student, parent, dashboard, faculty, branch, admin, app shell, CRM) and five Expo SDK 55 native apps (student, parent, staff, CRM companion, junior-lecturer). Web and native staff surfaces are treated as one product: a change to the faculty dashboard is not done until the staff mobile app ships the equivalent in the same PR. Frontends deploy to Cloudflare Pages, so the web tier costs nothing to keep warm.

AI that drafts, faculty who decide

Claude and OpenRouter models draft questions; nothing reaches students automatically. Generated questions land in a review queue with provenance recorded, which is why the bank can be audited today: 97,549 AI-drafted, 17,795 past papers, 11,955 faculty-authored, with 101,214 published, 12,855 approved and 823 still sitting in review. Langfuse traces the model calls, and a Lambda watches spend and alerts on provider credit failures.

Live classes, one Fargate task per class

Live classes run on mediasoup. A scheduler launches a dedicated Fargate task shortly before a class starts, the task self-discovers its public IP and writes its URL onto the class record, students join that task, and it is stopped when the class ends, with a reaper as the safety net. One class, one box, no idle SFU fleet.

What the numbers say, including the unflattering ones

The exam attempt path was load-tested with k6 against the dev API, ramping cohorts from 100 to 2,000 concurrent students. It handles about 500 cleanly and starts failing near 1,000, and the ceiling is entirely database-bound: Postgres pegged at ~100% CPU through every run.

At 497 concurrent students nothing failed, though submit p95 had already stretched to 12.2s. The named causes are unglamorous and fixable: a per-process connection pool of 10, a single event loop with no cluster, and an uncapped analytics cascade running inline on submit. Production runs on far bigger hardware than the box that was measured, so the real prod ceiling is higher and currently unmeasured. I would rather publish the measured number than the flattering one.

What came out of it

The roadmap item that mattered was productisation: could a second school run on this without forking the team? Four derivatives now exist, and I did most of the work on them.

• A CBSE / NEP 2020 school OS(237 merged PRs by me, 278 of its 329 commits), a separate Vite + React + Effect product that shares the platform's lineage, deployed for two school demos on their own AWS boxes. The demo boxes are currently parked, which is the correct state for a demo nobody is watching.
• A full client fork on its own AWS stack (30 merged PRs): separate RDS, Redis, S3, Lambdas, ECS services and Cloudflare Pages sites, plus a locked-down kiosk APK for exam stations.
• Two more branded college deployments (17 merged PRs each), running as their own ECS services in the shared cluster.

Trade-offs

• Dual-write instead of a cutover. The attempt rewrite could have been a flag flip. Instead it writes to both stores while the old path stays authoritative, which costs code and review time and buys the ability to compare the two on real exams before trusting either. In a product where a lost answer is a parent phone call, that is the right price.
• Web and staff mobile in the same PR. Every faculty feature ships twice, natively, before it merges. It roughly doubles the work per feature and it is the only thing that stops the two surfaces drifting into different products, which is what happened everywhere this rule was not enforced.
• Building the CRM rather than buying one.An off-the-shelf CRM would have been running months earlier. It would also have sat outside the platform's auth, data model and reporting, and an admissions conversation would never have joined up with the student record it eventually becomes. The cost is that the CRM is still on staging.
• One Claude pass plus a human queue, not an auto-grader. A reranker would be a nice optimisation. A faculty member approving each question is what made AI generation acceptable to the school at all, and the 823 questions sitting in review right now are the mechanism working, not a backlog.

Outcome

Brilliance is live and load-bearing for a 12-campus college group, and it has been the densest engineering work of my career: 447 merged pull requests in five months, across a Hono API, a Postgres schema, eight web apps, five native apps and an AI voice service. The patterns I now reach for by default came out of it: a typed monorepo where drift stops at the type checker, AI with a human gate and recorded provenance, guardrails enforced in CI rather than in review comments, and features shipped dark behind flags until the data says they are safe.