Registech

HOW THIS STARTED

I didn't set out to build school software

The first time I looked closely at how a small school near Jaipur actually runs, I went in expecting to find some kind of system. A spreadsheet, an old laptop in a back room, anything. There was nothing digital at all. Admissions, attendance, fees, every student who had ever walked through the gate — it all lived in paper registers, and most of it lived in one person's head. That stayed with me. Not because it was failing. It worked, in the way a thing held together by one very capable, very tired person works. But it didn't scale, it didn't survive an audit without a small panic, and it was one spilled cup of chai away from real trouble.

THE REAL PROBLEM

The problem was never that they needed an app

The easy version of this story is "rural schools have no tech, so give them tech." I don't think that's the real problem, and I think getting that wrong is exactly why so little software reaches these places. Almost every tool I looked at was built for someone who already knew how to use it — steady internet, a spare device, a user comfortable clicking around and undoing their own mistakes. None of that describes the person actually doing the work. So the real problem was narrower and harder: how do you move someone off paper without making them feel slow for having been on paper in the first place? The register isn't the enemy. The Sunday afternoons lost to it are.

"Every tool I looked at was built for someone who already knew how to use it. None of them were built for the person actually keeping the school running."

WHO IT'S FOR

One user. Everything else bends around him.

I wasn't designing for students, or parents, or some district dashboard nobody asked for. I was designing for the administrator. Usually one person who is also the accountant, the registrar, often the principal, and the IT department by default. He has run the school on paper for years and he is good at it. He is not sitting around waiting to be saved by an app — if anything he's a little suspicious of one, and honestly he's right to be. Winning him over wasn't a feature problem. It was a trust problem.

THE BET

The whole system was the temptation. So I didn't build it.

There is a full academic management system in my head — enrollment, attendance, fees, report cards, parent updates, all of it. The obvious move is to build that. It's also the fastest way to lose a first-time user. Ten features handed to someone who has never used software like this isn't power, it's noise, and noise gets ignored. So I made a bet I keep coming back to: pick the single most painful, most frequent job, do it noticeably better than paper, and earn the right to add the next one. For these schools, that job was enrollment.

WHAT I SHIPPED

Three things, each designed to feel like less, not more.

One question for every feature: would Suresh use this without anyone standing next to him?

• F1

  One-screen enrollment

  Same fields, same order as the paper form he already fills out. Familiar on purpose — there's nothing new to learn, which is the entire point.

• F2

  Searchable records

  Type a name, get the student. The register without the page-flipping, and without a misplaced sheet quietly turning into a lost child.

• F3

  Offline-first, low-end-friendly

  Saves on the device, syncs when a signal shows up. Runs on a five-year-old phone and a shaky connection, because that's what's actually in the room.

TRADEOFFS

Every cut was a bet about what a school could actually absorb.

• SIMPLE VS POWERFUL

  I mirrored the paper form instead of designing a 'better' one. A more powerful form he won't open is worth less than a plain one he'll use on the first day. Simple was the harder thing to build, and the right one.

• ONE JOB VS THE WHOLE SYSTEM

  Shipping enrollment alone felt almost embarrassingly small. But a narrow thing that works beats a complete thing that overwhelms. The roadmap is real — it just has to be earned, not assumed.

• FAMILIAR VS MODERN

  I dropped clean, modern UI patterns wherever they fought his mental model. Looking like the register he already trusts mattered far more than looking like a polished app.

• OFFLINE VS ONLINE

  Building offline-first was more work and slowed v1 down. But a tool that needs steady internet is a tool that doesn't work out here. That one wasn't really a tradeoff — it was the floor.

WHERE IT STANDS

Three schools said yes. That's the part I'm proud of.

This is early, and it's meant to be. Three schools have signed on as pilots and are onboarding now. For one of them, an admin enrolled a student digitally without me walking him through it — and that small, unglamorous moment is the whole thing. The number I actually care about isn't pilots signed, it's how often the tool gets used when I'm not in the room. Everything after this — attendance, fees, the rest of the system I keep sketching — only gets built if this first piece earns it.

WHAT I'M TAKING FROM THIS

Building for low tech-literacy rewired how I think about scope.

• Designing for this user taught me to subtract.

  My instinct as a PM is to add. Out here, almost every feature I removed made the product more likely to get used. The hard skill wasn't deciding what to build — it was the discipline to not build it yet.

• Trust is the feature. Everything else serves it.

  These admins have no reason to believe a stranger's software won't waste their time. You don't earn that with a feature list. You earn it by making the first thing so obviously useful that they're willing to try the second.

• Meet people where they are, not where the roadmap wants them.

  The version of Registech that helps these schools looks a lot more like their paper register than like a modern dashboard. That was humbling to accept, and it was clearly the right call.