One founder. Ten weeks. A full institute operating system.
Nirai is a multi-tenant platform that runs a coaching institute end to end, from the first enquiry to the final rank list and the audited books. It was designed and built by one person between 13 July and 25 September 2026, with Claude Code as the engineering team and Claude working inside the product itself.
The challenge
The institutes that most need good software are the ones that can least afford it.
Testware Informatics has spent more than fifteen years building assessment and operations software for competitive-exam institutes across South India. In that time one pattern never changed. The large national brands buy serious systems and run beautifully. The small and mid-size centre, the one with three branches and four hundred students preparing for UPSC or TNPSC or NEET, runs on a stack of spreadsheets, a WhatsApp group, a receipt book and one overworked manager who remembers everything.
It is not that nobody built software for them. It is that an honest version of that software is enterprise scope. To genuinely run a multi-branch institute you need admissions with a real CRM, fees with concession approvals, double-entry accounting that an auditor will accept, an online assessment engine that handles mathematics and chemistry and diagrams, attendance that cannot be faked by a friend with a phone, staff and payroll, inventory, a student portal, a parent view, compliance records, and a website the institute can actually sell from. Fifteen distinct problem domains, each one a product in its own right.
Priced the conventional way, that is a team of eight to twelve people across backend, frontend, QA and infrastructure, working for eighteen to twenty-four months. The software that comes out of that has to be sold at a price that funds the team that built it, which puts it permanently out of reach of exactly the institutes who need the systems most.
So the question was not whether we knew what to build. After fifteen years inside these institutes, that part was clear. The question was whether one person who understands the domain deeply could build enterprise-grade software at a cost that lets a four hundred student centre afford it.
How Claude was used
Claude does two completely separate jobs here, and it is worth separating them clearly. It built the product, and it also works inside the product.
Claude Code as the engineering team
Architecture, implementation, tests, code review, production debugging, infrastructure runbooks and print collateral. One human making the product decisions, Claude Code doing the engineering against them.
The Claude API inside Nirai
Two shipped features call Claude at runtime: the AI Question Studio that drafts exam questions for a human to verify, and the Website Builder that writes an institute's marketing site. Both are metered through an internal credit wallet.
The working method that made it hold together
Speed without discipline produces a demo, not a platform. Three rules kept the output honest, and Claude Code enforced all three more consistently than a human team usually manages.
The specification leads the code
A spec/ tree is the product source of truth. Architecture is written down as locked, and real uncertainties are marked OPEN DECISION so they reach a human instead of being guessed. Spec and code change in the same commit.
Tests follow the bug that happened
The valuable tests here are not the happy paths. They are regression tests written the moment a production failure was understood, each carrying a comment naming the failure mode so it cannot quietly return.
Diagnosis comes from evidence
The habit that saved the most time was refusing to speculate. Response headers, response bodies and logs first, hypothesis second. Three of the four bugs below were invisible in the source and obvious in the headers.
Four real examples, not illustrations
Every one of these is a problem that came up during the build and is fixed in the shipped code today.
The mobile app opened to a blank white screen, and the network tab said everything was fine
Two independent faults compounding. The single-page shell was being served cacheable, so a home-screen install kept a copy that named JavaScript bundles which no longer existed. The server then answered those missing bundle requests with the shell HTML and a 200, so under nosniff the browser refused to parse a module and mounted nothing at all. Diagnosed from the response headers, not from the code. The fix makes the shell uncacheable and makes a missing build artefact return a true 404, and both behaviours are now pinned by tests that explain why they exist.
A booking slot, once cancelled, must not stay blocked forever
Demo bookings need a database guarantee that two leads cannot take the same slot. MySQL has no partial unique index, so a plain unique constraint on the slot would keep a cancelled slot locked for all time. The shipped design carries the slot in a nullable unique column that is set to NULL the moment the booking is cancelled, so uniqueness applies to live bookings only and the slot returns to the pool. The reasoning is written into the migration.
A reminder job silently sent every stale message it should have burned
The guard that suppresses long-overdue reminders compared a time difference against a grace window, and in Carbon 3 that difference is signed by default. The comparison therefore never fired. It was caught by a test that asserted the opposite of what the code did, and the fix uses explicit timestamp arithmetic with a comment naming the trap, because the original line looked perfectly correct.
Government holidays, read from the gazette instead of assumed
Demo scheduling skips Indian and Tamil Nadu public holidays. The first implementation treated Pongal and Thiruvalluvar Day as fixed calendar dates. Reading the actual Tamil Nadu government holiday notification proved otherwise, and the calendar was restructured to separate gazette-confirmed dates from provisional almanac dates, with the confirmed data superseding the provisional and an explicit expiry so unverified future years can never silence the staleness warning.
Claude inside the product
The feature that matters commercially is the AI Question Studio. A small institute cannot sell a test series, because producing thousands of verified questions needs a subject-expert panel it cannot hire. Nirai drafts the question set with Claude and routes every single item through human verification before it can enter a live paper. The AI removes the blank page. The institute's own faculty remains accountable for correctness, which is the part a coaching brand can never outsource.
The Website Builder does the same for an institute's public presence, generating a structured marketing site from the institute's own details that staff then edit in plain language. Both features draw on a metered credit wallet with per-tenant cost reporting, so an institute always knows what it has used.
What shipped
Not a prototype and not a thin wrapper over a template. Fifteen functional modules on a multi-tenant Laravel and React platform, where every institute is provisioned its own database for genuine isolation and per-tenant export or erasure, and every module is gated by an entitlement check so institutes differ by configuration and never by a code fork.
The platform underneath
Laravel 13 and PHP 8.3 on the server, React 19 and TypeScript on the client, a modular monolith with hard internal boundaries, database-per-tenant isolation, role and entitlement based access, and a management console for the platform operator. Hosted in Bangalore, so Indian institute data stays in India under DPDP.
Where mobile stands today
The live mobile experience is an installable progressive web app, individually branded per institute, and it works now. A native iOS shell is scaffolded in the repository and app store submission is still ahead of us. We would rather say that plainly than claim store apps we have not shipped.
Results
Everything in the left column is measured from the repository. Everything in the right column is our own estimate of what this same scope costs built conventionally, based on fifteen years of delivering software of this kind.
| Measure | Nirai, built with Claude Code | Conventional build, our estimate |
|---|---|---|
| Elapsed time | 74 days, 13 July to 25 September 2026 | 18 to 24 months |
| Engineering team | One person, founder and architect | 8 to 12 across backend, frontend, QA, DevOps |
| Functional modules | 15, plus the AI Question Studio | Same scope, phased over several releases |
| Commits | 327 | Comparable, spread across the team |
| Automated tests | 526 across 90 files | Usually the first thing cut under deadline |
| Lines of code | About 74,500, server and client | Comparable volume |
| Specification discipline | Spec tree is source of truth, updated in the same commit as the code | Documentation drifts from code within weeks |
| Who holds the domain knowledge | The person writing the code | Translated through analysts and tickets |
On the comparison. The left column is countable and we have shown how to count it. The right column is an experienced estimate, not a controlled trial, and we are not going to dress it up as one. The claim we will defend is narrower and more interesting: this scope, at this level of test coverage and architectural consistency, was not reachable by one person before. We tried the conventional route for fifteen years.
The result that surprised us most was not speed
It was consistency. In a team build, module twelve rarely looks like module one, because four people with four mental models have been through it and the original architecture has been reinterpreted at every handover. Here the architectural decisions were written down once, read at the start of every session, and applied identically to the accounting ledger and to the grievance workflow. The second surprise was how much of the time went into judgement rather than typing. The genuinely hard parts of this build were decisions, such as where the compliance liability should sit in a telephony integration, or whether concession approvals need an approval matrix. Those still took as long as they ever did. What collapsed was the distance between making the decision and having it correctly implemented and tested.
What we are not claiming
- Not a finished company. Pilot institutes are onboarded and running on the platform. We are not yet operating at scale, and we will not imply that we are.
- Not store-published mobile apps. The progressive web app is live, the iOS shell is scaffolded, store submission is pending.
- Not autonomous software. Every architectural decision, product call and commercial trade-off in this build was made by a human who has spent fifteen years inside these institutes. Claude Code did the engineering, not the deciding.
- Not a zero-defect build. The four examples above are real bugs that reached a running system. They are in the case study because catching and fixing them quickly is the actual story.
What it means for the institutes we serve
An institute does not care how its software was built. It cares what the way it was built does to the price, the speed and the answer it gets when it asks for something. On all three, this changes.
The price floor drops
Software has to be priced to fund the team that maintains it. A build that did not need twelve engineers does not need the licence fee that pays twelve engineers, which is what lets a three branch centre run the same system as a national brand. That is the whole of our vision, turned from a slogan into arithmetic.
A feature request stops being a quarterly negotiation
When an institute asks for something specific, such as capturing which bank account received an offline fee payment, the honest answer is now weeks rather than the next major release. Our own demo scheduling system, with holiday handling, confirmation email and reminders, went from decision to production inside a week.
Small institutes get capabilities that were previously out of reach
Selling a test series used to require a subject-expert panel. With AI drafting and institute faculty verifying, a centre with four teachers can run and sell a credible test series. The verification step is deliberate. It is what keeps the institute's name safe, and it is the part we will not automate away.
Fewer vendors to trust, and clear lines about liability
One connected platform replaces the tangle, and where we integrate someone else's service, such as payments, messaging or telephony, the institute brings its own provider account and stays the business of record. We hold the operations, not the regulated liabilities. That line is deliberate, and written into the specification.
Where we go next
The same method continues. Analytics, deeper proctoring, cloud telephony in the admissions CRM and a digital proposal flow are specified and queued. Each one will reach production the way the last fifteen modules did, which is specification first, implemented and tested with Claude Code, and judged by whether a non-technical front desk assistant in Chennai can use it on day one without being trained.
The platform in this case study is live. Go and open it.
A seeded demo institute with real curriculum, students, papers and books. No form, no sales call first.