Case A-005.02 · OWN PRODUCT

NyayHub — case management for the way Rajasthan High Court actually runs

StatusBeta · Q2 FY26
NyayHub — case schematicAn architectural section view. Three small tenant firm boxes sit at the top, marked FIRM A, B, C. Two prominent red dashed isolation walls run floor-to-ceiling between them, labelled RLS · ISOLATION at the midpoint. Below the tenants sits an IndexedDB cache layer drawn as three offset stacked rectangles. The foundation is a wide thickened rectangle, doubled with an interior line, labelled DATA PROTECTION PLAN 1. On the right edge, a Wi-Fi wave with a slash through it sits at the cache layer. Caveat note: "court Wi-Fi optional".NYAYHUB · STRUCTURAL SECTION · A-AFIRM · AFIRM · BFIRM · CRLS · ISOLATIONINDEXEDDB · CACHE-FIRSTDATA PROTECTION PLAN 1court Wi-Fi optional
Client
Izafa Labs (own product)
Engagement
Architecture, build, operations
Stack
Next.js 16, Supabase (~70 tables), Edge Functions (30+), IndexedDB
Status
Beta · Q2 FY26

Most legal case management software is built by people who have never sat through a Rajasthan High Court hearing. So I built one that was.

Not client work — but I publish it here because the engineering decisions are the same ones I make for clients.

The premise.

NyayHub is built around the constraints that actually break legal software in India: unreliable Wi-Fi inside court buildings, multi-tenant data segregation across firms, and the fact that lawyers need their interface to load before the judge calls the matter.

The architecture.

Seventy Postgres tables on Supabase, thirty Edge Functions, and a strict multi-tenant isolation model I call Data Protection Plan 1. The frontend is built around Optimization Plan 1 — cache-first rendering, IndexedDB-first UI, non-blocking realtime, and aggressive query invalidation reduction. The default state assumption is offline; the network is treated as enhancement, not requirement.

What this proves about how I engineer.

Constraints first, features second. Multi-tenancy designed at the database layer, not bolted on. Realtime and offline reconciled at the architecture level, not patched at the component level. This is the engineering posture I bring to client work.