The first thing I was hired to do wasn't development.
"Just check whether our code is healthy." Read the code, point out what needed fixing, file the bugs, track them. Code management, basically. Writing the software was never the engagement.
BNZ ran an EdTech service (Hiqsum) connecting teachers and students in real time. The system had been built by an outside vendor over three years. I came in to manage that codebase.
Then I started reading it — and the problem wasn't a few bugs.
It wasn't bugs. It was the structure.
Here are the symptoms the (non-technical) founder was living with:
- The service stuttered at around 50 concurrent users. A handful of academies online at once was enough to slow it down.
- Server costs were high relative to the actual scale.
- Features broke often, and in the same places — not one-off bugs, the recurring kind.
- Shipping was slow, and "we can't do that" was the default answer.
This isn't about anyone being incompetent. When a system runs one direction long enough, it tends to look like this: giant do-everything queries, inefficient joins, responses that blew past 30 seconds without blinking, a database with no connection pooling, no version control. The frontend even issued commands directly to the backend to execute.
The more of the code I read, the clearer it got: this wasn't going to end with a few fix requests. Every piece was the kind of design that runs today and collapses the moment it grows.
The scariest problem: nobody picks up when it goes down
The founder told me about one in particular.
The vendor hadn't just built the system — they ran the operations too. One holiday, the service went down. And nobody could be reached. The service was dead, academies couldn't manage their members, and the person who could fix it was unreachable.
For a live service people use every day, that isn't a small inconvenience. It's the worst kind of failure. A missing feature can wait. A frozen service with no one answering the phone cannot.
And it wasn't only in the past. While I was assembling a team, we kept some work with an outside vendor in parallel — and during that stretch, contact dropped more than once, citing personal leave we were never told about in advance. Incidents always hit at the worst time, and I experienced that "no one's reachable right now" moment myself.
This is less a question of one person's diligence and more a structural one. When you tie operations entirely to an outside vendor, accountability never collects in one place. It runs fine most days — and the gap shows the instant everyone is away at once.
I was only managing the code. I proposed rebuilding it anyway.
This was the first call I made.
My role was to manage the code, but the root cause was the structure. You can squash a hundred bugs and the hundred-and-first shows up in the same place. So I told the founder: instead of repeating fix requests, let's build a team and rebuild the foundation.
It was well outside the role I'd been given. But I judged it was the right path, and the founder agreed. We built a team and re-laid the base.
- Made it scale. Distributed processing and sticky sessions removed the 50-user ceiling.
- Moved costs to usage-based. Migrating to cloud (App Engine) meant paying for traffic, not a fixed leak.
- Restructured front and back. Broke the monolith into microservices and components, so fixing one place didn't break another.
I fixed operations too: defined who responds to an incident and how, and set up deploys and monitoring. Step one was making sure the "no one's reachable" situation simply couldn't happen anymore.
Once the foundation changed, the features that had been "impossible" started shipping fast: pop quizzes, a fix for the chronic chat bugs, bulk upload that auto-splits a PDF or image into individual questions, better question search, video-lecture streaming (.ts) with watch-progress tracking, a community, Zoom meeting scheduling. The stalled roadmap started flowing again.
That's the "make it stop breaking" part. The real change came next.
It turned out to be a business-model problem, not a tech problem
Once the tech was sorted, the thing actually blocking growth wasn't the code. It was the model.
The setup was: academies subscribed into one shared platform. To an academy, it felt like renting space on someone else's product. So I made the second call.
Not subscriptions — give each academy its own branded app.
We moved to a structure where every academy got its own white-labeled app. They were no longer bolted onto someone else's service; they had "our academy's app," and the psychological and brand barrier to adoption dropped.
The result showed up in the numbers.
When we relaunched on the new model in late September, there were 6 concurrent users. Those 6 became ~1,000, and contracted academies grew to 14.
That wasn't a change made with a line of code. It came from a business decision — how do we sell this thing.
The guy hired to manage the code became the CTO
My role shifted along the way. The person who came in to manage a codebase ended up as the company's CTO, owning the system, the operations, the team, and the product direction.
Looking back, the one thing BNZ taught me: reviving a stalled project isn't "fixing." It's "re-deciding." And the place you re-decide is often not the code — it's the business model, or the question of who is accountable.
If you're a founder staring at this
Maybe this sounds familiar.
You outsourced for years, and at some point all you get back is "that can't be done." It slows down the moment users grow, and the server bill makes no sense. Features keep slipping, the same bugs keep returning. The service went down over a holiday and you couldn't reach anyone who could fix it.
If so, what you need probably isn't "someone to review the code." You need someone who'll decide what to rebuild, what to throw away, what to change — and own it to the end. Someone who picks up when it breaks. Sometimes the answer isn't in the code. It's in the model, or in the structure of who's responsible.
Have you ever inherited a system like this — where the real fix turned out not to be code at all? I'm curious where other people drew the line between "patch it" and "rebuild it."
