239,000 students use this platform. I built it over 7 years. I was never a full-time employee.
That's the part that surprises people. Seven years as the technical backbone of an EdTech company recognized on the Inc 5000 list — as a fractional contributor, not a salaried employee.
The Starting Point
When I joined, the platform served a fraction of its current user base. The infrastructure was early-stage, the team was small, and the technical decisions made in those first months would determine whether the product could scale or would collapse under its own weight.
The Decisions That Mattered
Over seven years, there were moments where the product could have died:
The architecture pivot. Early infrastructure choices that would have crumbled at 50,000 users. We rebuilt the foundation while keeping the platform live. No downtime. No "sorry, we're migrating."
The scale challenge. Going from thousands to 239,000 active students isn't a linear problem. Authentication systems, database queries, content delivery — everything that works at 10K breaks differently at 100K and again at 200K. Each threshold required rethinking, not just scaling.
The invisible work. The features that never shipped because they would have created technical debt. The security patches applied before anyone noticed the vulnerability. The monitoring that caught issues at 3 AM. This is the work that a project-based consultant never does — because their engagement ends before the consequences show up.
The Result
Why This Matters For You
Most technical consultants optimize for the project. Ship it, document it, move on. That works for a build. It doesn't work for a product.
If you have a product that needs someone who thinks in years, not sprints — someone who'll be there when the architecture decision from month 3 comes back to haunt you in month 30 — that's what I do.