Nexli

Nexli is a school operating system: multi-tenant, bilingual in English and Hindi, built for the specific reality of Indian K-12 schools where one platform needs to serve students, parents, teachers, administrators, and finance staff without any of them stepping on the others' data. Seven distinct login experiences, one shared Firestore database per school, real workflows underneath: attendance, fees, admissions, report cards, a holistic progress card aligned to India's newer education policy, hall passes, transfer certificates, a question-paper maker, an exam mode that temporarily elevates an invigilator's permissions and then revokes them automatically when the exam window closes. It's the most ambitious thing I've built, by feature count, and by a wide margin.

I'm going to describe it honestly, because the honest version is more useful than the polished one, and because I think a founder who can say plainly where a project actually stands is worth more trust than one who can't.

The single most honest sentence in my own project files

My own status document says it directly: Nexli is not production ready and not publish-ready today. And it goes further than that: a real, often well-tested backend core exists, and a real, often well-designed business-rule layer exists, but the two are frequently not connected to each other. The client mostly runs against in-memory seed data, not real persistence. Out of roughly eighty-seven feature modules, only three (student directory, attendance, and the finance module) actually read and write to a real database today. Everything else runs on mock data, by explicit design, not oversight, while the underlying architecture waits for the rest to be wired up module by module.

If I'm scoring it the way I'd score anyone else's project: feature presence, meaning a module exists, is routed, and is reachable in the UI, sits around ninety-three percent. Actual production-ready completeness, meaning real persistence plus correct permissions plus passing tests plus no orphaned UI, sits closer to five percent. That gap is the single most important number in this whole project, and it's the one I'd want anyone evaluating Nexli to see first, not last.

Two codebases, and I won't pretend that's clean

There isn't one linear Nexli. There's a deeper research build, with eighty-seven feature directories and a full Cloud Functions backend, and a separate, earlier, simpler build with fifty-two modules and no functions backend of its own. Same product name, two genuinely different snapshots of the same idea, not one clean line of iteration from version one to version two. That's not a structure I'd recommend to anyone, and it isn't the structure I'd choose if I were planning this from scratch today. It's what happened when I kept discovering better ways to build parts of this system and didn't always carry the earlier build forward cleanly before starting the next attempt. The simpler build has its own honest self-scored launch-readiness number, tracked over time as it improved: starting near two and a half out of ten, climbing through five, then six, landing recently around seven, which its own status doc calls close to the honest ceiling for what code alone can fix, with the remaining gap being real-world steps outside the codebase: upgrading Firebase's billing plan, wiring an actual payment gateway, getting a lawyer to review the terms, rotating some early API keys.

What an honest audit actually found

I ran a real, thorough pass across this project (eleven separate audit angles compared against the entire codebase in one sitting), and some of what it found is worth naming directly rather than smoothing over. A seeded role called registrar held two permissions that should never coexist under the platform's own separation-of-duties rule (the ability to delete student records and the ability to issue certificates), meaning that built-in role, if anyone tried to actually assign it, would throw an error the moment the system checked its own rules against itself. For months, both the parent and student portals, fifty-four routes between them, checked only whether you were logged in as a member of that portal, never whether you actually held the specific permission the page required. A logged-in student could navigate directly to nearly any URL in their portal regardless of what they were supposed to be allowed to see. And a confidentiality flag on meeting-minutes records, meant to protect sensitive committee discussions, was stored correctly but never actually enforced on read: any staff member with generic minutes-reading permission could see records marked confidential.

I'm naming these because a school platform that gets access control wrong isn't a minor bug category. It's the whole point of building it multi-tenant with real permissions in the first place, and finding these gaps through a deliberate audit, before any real school's data was ever at risk, is exactly what that audit process was for.

The part that dwarfs the actual product

Separately from the app itself, there's a content operation attached to Nexli that's genuinely larger, in raw output, than the product: nearly two thousand blog articles across twenty categories, several hundred thousand words, fact-checked against a dedicated reference document, produced largely through an autonomous writing process I directed rather than authored line by line. I mention this not as a brag but as an honest data point about where the actual hours went during parts of this project's life: a huge volume of content work running in parallel with a product core that, by comparison, still has most of its persistence layer unbuilt.

Why the pricing isn't public yet

I've fully modeled Nexli's pricing internally: a founding-school rate, capped deliberately at two or three schools at a time, priced low enough that the real constraint isn't server cost, it's my own time supporting early customers directly. None of that is on the live site. The site says "contact for pricing" on purpose, until there are real paying reference schools to point to, because publishing a price list for a platform that's honestly five percent production-ready would be a promise I'm not in a position to keep yet.

What finishing this actually means

Wiring the remaining eighty-plus modules to real persistence, one at a time, the same way the three that already work got there. Closing the parent and student portal permission gaps for good, not just patching the specific holes the audit found. Reconciling the two codebases into one, honestly, instead of letting them keep drifting further apart. None of that is mysterious work. It's just a lot of it, and I'd rather tell you that plainly than let a well-designed demo imply the harder part is already done.

Full stack developer. Founder of Yashveer Labs. The plans for this one are the most ambitious I've written. The build is honestly still catching up to them, and I'd rather you hear that from me than discover it yourself.