Case Study: The EdTech Problem So Hard We Built Our Own OS for It

I can't name this product. It operates in a corner of edtech where being identified too early is a competitive risk, and we're not done growing yet. So this case study is anonymized: no product name, no client names, no exact revenue. Everything else is real.

What I can tell you is why nobody had built it before us, how we built it, what broke along the way, and what it looks like when a product starts working well enough that your competitors stop ignoring you and start calling you.

The problem nobody wanted

Edtech has a handful of famous problems that everyone piles onto: content delivery, engagement, test prep, admin software. Then there are the problems everyone in the industry knows about, complains about, and quietly steps around.

This was one of those. It had stayed unsolved for a simple, unglamorous reason: it didn't fit inside any one engineer's skill set.

Solving it properly needed operating-system-level Linux work and it needed a modern web application. It needed DevOps that could survive real institutional environments, not just a clean cloud deployment. It needed Python for the data and AI side. It needed serious security thinking, because the whole point of the product only holds if it can't be trivially defeated. And in places where the standard protocols didn't do what we needed, it needed new ones designed from scratch.

By the time we shipped, the codebase spanned seven programming languages. That's not something I'm bragging about; in most products, seven languages is a smell. Here it was the honest shape of the problem. Web stacks don't speak to network layers, network layers don't speak to AI pipelines, and the glue between them is where all the hard work lived.

That breadth is exactly why the problem sat untouched. A web team would look at it and see the systems work they couldn't do. A systems person would see the product and AI work they couldn't do. An agency would quote it, sign it, and drown. It needed one team, with one person who could hold the whole picture, willing to go deep in every layer at once.

That's the gap we walked into.

What we built

The short version: an edtech product that sits close to the infrastructure, watches what actually happens rather than what people report, uses AI where patterns are too messy for rules, and reports to the people who need to act on it.

The build drew on the full stack, in the literal sense:

• A Linux-based OS, built from zero. Not a hardened distro with our app on top: our own operating system, with the code built and ported across targets including mobile Linux. This is the layer that made most teams walk away, and it's where the defensibility lives.
• MERN for the application layer: the dashboards, the workflows, the parts humans touch every day.
• Python and AI for the analysis: separating signal from noise in data that has no clean labels and no textbook structure.
• Custom protocols where existing ones didn't fit. Designing a protocol sounds glamorous; in practice it's weeks of boring edge cases. But when off-the-shelf doesn't do the job, you either design or you compromise the product.
• Security as a design constraint, not a feature. My M.Tech is in cybersecurity, and this is the project where that background stopped being a credential and started being the roadmap. A product like this gets probed by the very people it serves. If it only works against honest users, it doesn't work.
• DevOps built for hostile terrain: institutional networks, inconsistent hardware, environments where you don't control the machines you run on.

And then there was the part no job description covers: the hardware. Software people like to stop where the device begins. We couldn't. We sat with the manufacturers themselves, in their facilities, to understand their equipment from the inside, then integrated our SDKs with theirs. More than once, when their side didn't do what the integration needed, we wrote the code for them. That's what it takes to ship software that has to work on hardware you don't make: you go to where the hardware is made.

The hardest part

The hardest part was never one layer. Any competent specialist could have built any single piece of this. The hard part was that every layer constrained every other one, and no decision could be made in isolation.

The protocols were the clearest example. Designing a protocol sounds glamorous from the outside. In practice it was weeks of boring edge cases: what happens on flaky institutional networks, what happens when a machine dies mid-run, what happens when someone actively tries to game the exchange. Every one of those answers rippled into the systems layer, the application layer, and the AI pipeline at once.

And underneath all of it sat the security constraint: this is a product whose own users have an incentive to probe it. Every convenient shortcut we considered, we had to evaluate as an attacker first and an engineer second. That discipline slowed us down for months. It's also why the product held up when it mattered.

What almost broke it

After all the protocol design and the security reviews and the seven languages, the thing that nearly took us down was one line.

A single line in our AWS load balancer configuration was wrong. Not the AI, not the custom protocols, not the systems layer everyone said was too hard: a small, boring line in the infrastructure that everything else stood on. It failed initially, quietly, the kind of mistake that does nothing in a small test and everything in a big one. Under the load of a real run it would have taken the product down in front of the exact audience we had spent years preparing for.

We found it at the last moment. Everyone around us had been wishing us luck for the launch; catching that line was the blessing they were all wishing for, arriving in its actual form. Luck in production looks like someone rereading a config file one more time.

That's the honest lesson of the whole build: breadth got us to the run, discipline got us through the review, and the thing that decides the day is still whoever checks the last boring line.

Where it is now

For years, the organisations we now serve had no choice but to buy this capability from outside vendors, at a hefty price, because nothing purpose-built existed. We started the same way ourselves: running on old software stitched to third-party tech, where a big run meant working in the thousands. That was the ceiling, and everyone in the space had learned to live with it.

Then our own product was ready. The first time we ran it at full confidence, we ran 500,000 assessments in one go. In a single hour.

Not a benchmark in a lab. A real run. From "thousands, carefully" to half a million in sixty minutes is not an optimisation, it's a different category of product, and it's the moment every layer of that seven-language stack paid for itself at once. The systems work, the custom protocols, the DevOps built for hostile terrain: that's what they were for.

Beyond that run, the product is doing better in the industry than we ever projected. We set targets we thought were ambitious, and reality has been embarrassing them.

And there's a second signal I've come to trust more than any dashboard: the competition found my number. Companies in the space keep reaching out with genuinely attractive offers: acquisition interest, partnership structures, roles. I take those calls politely, and I hold my horses. When incumbents try to buy the thing you built in a space they said wasn't worth building in, that's not a distraction. That's the market grading your work.

What this project taught me

Unsolved problems are often staffing problems in disguise. This one didn't need a genius. It needed breadth: someone who had done Linux and web and DevOps and AI and security for real, and could design across all of them at once. If a problem in your industry has stayed open for years, ask whether it's actually hard or whether it just doesn't fit the shape of the teams that looked at it.

Breadth is a moat. Features can be copied in a quarter. A stack that spans seven languages and custom protocols, built to survive adversarial users, cannot. Our defensibility was never one clever idea; it's the accumulated systems work competitors would have to repeat.

Security can't be retrofitted onto a product whose users will attack it. We designed for the hostile case from day one. Every shortcut we refused early is a breach we didn't have later.

Hold your horses when the offers come. The first acquisition interest arrives exactly when the product starts compounding. Selling at the first flattering number means selling right before the curve you worked years to reach.

---

This is the kind of build I take on as a technical co-founder and the kind of judgment I rent out as a fractional CTO for AI-first startups: the calls about what to build, what to design from scratch, and which problems are more solvable than they look. If your industry has one of these "nobody touches it" problems, I'd like to hear about it.