An operating systemfor institutions.

An institution is a graph, not a form.

A tree of audiences — classes, batches, sections, groups — containing people with role + permission scoping. Every operational artifact — a test, an attendance session, an invoice, an announcement — is scoped to an audience and is individually auditable. One data model, adapted per org type by configuration, not forks.

A teacher fixes a typo mid-exam.

Question 3 gets edited while 40 students are mid-test and 200 have already submitted. If grading reads the live question, the fix silently changes what past students were graded against. Version every edit and you inherit a versioning table and migration pain forever.

On attempt start, the whole resolved test form is serialised into an immutable formSnapshot on the Attempt row. Rendering, autosave, auto-grading and manual grading only ever read the snapshot. The live ContentItem is free to change — it only affects attempts started after. In parallel, an enforceTestLockdown middleware sits in front of every Notes and Content route and rejects a second tab reaching for another test's answers, entirely server-side.

Why it's hard — It's a cross-cutting concern that has to be correct on dozens of routes, must never lock a student out of the test they're taking, and must not depend on any frontend cooperation.

“What classes actually happened?” isn't a lookup.

The answer is: the recurring weekly timetable, minus holidays, minus cancellations, plus extra classes, with reschedules moved, and any session that already has attendance locked to what actually occurred — substitutions included. Naively it's an O(days × entries) merge with a dozen precedence rules and easy double-counting bugs.

One service builds the result in ordered passes over a single keyed map. Base entries expand across the range; attendance sessions fold in (cancelled deletes, active overlays via a precedence chain so partial data never blanks a field); a slot already marked done is never overwritten; then filter and sort. That one function backs four separate screens, so its correctness is load-bearing.

Why it's hard — Every precedence rule is a chance to double-count or blank a field, and the same function has to be right for the planner, the two read views, and the take-attendance screen at once.

Money must never be wrong.

Checkout is the most retried, most double-clicked, most network-flaky flow in the product. A double-submit must never create two Razorpay customers, two subscriptions, or two active plans. And auto-generating recurring invoices is where fee software destroys trust — one bad plan silently writes hundreds of wrong invoices.

The checkout is idempotent end to end — customer reuse from the DB, subscription reuse for in-flight states, an idempotency key on creation, and a hard block when an active plan already exists. Fees are split into configuration (fee plans, Zod-enforced) and financial truth (immutable-ish invoices, amount always derived from the breakdown). Nothing auto-creates: the flow is Preview → Confirm → Generate, and the preview flags existing invoices before a single row is written.

Why it's hard — Same inputs must give the same result regardless of retries or races — and “nothing happens silently” has to hold even when an admin fat-fingers a plan.

Four tabs, one expired token.

A user has the console open in four tabs. The access token expires, all four fire requests, all get 401, all try to refresh at once — the refresh-token rotation races and three of the four fail with a now-stale token, logging the user out.

A single shared axios instance whose 401 interceptor dedupes concurrent refreshes into one in-flight promise, queues every request that 401'd during the refresh and replays them once the new token lands, and coordinates across tabs over a BroadcastChannel so exactly one tab performs the refresh and the rest adopt the result.

Why it's hard — The failure mode is invisible until it isn't — it only shows up with multiple tabs and an expiry, and the cost of getting it wrong is silently signing people out.

Fast by construction, not by caching later.

The dashboard is where everyone lands, and it's the easiest place to ship a query that scans every student, session or invoice in a 5,000-person org on every page load.

An explicit, documented query-classification discipline: cheap indexed counts and bounded lists on the dashboard, windowed queries allowed with a supporting index, and genuinely expensive reconciliations pushed to a reports surface. Every widget fetches independently and renders its own loading, empty and error state — one slow widget never takes the page down — with short cache TTLs and a KPI that deep-links to a URL-stateful filtered page.

Why it's hard — The discipline only works if it's written down and enforced — one well-meaning join on the landing page and the whole thing is slow for the largest customers.