Building HeyTutor
Owning the architecture, infrastructure, hiring, and roadmap of a tutoring marketplace from 2016 to 2025 — and handing it off clean.
Owning the architecture, infrastructure, hiring, and roadmap of a tutoring marketplace from 2016 to 2025 — and handing it off clean.
In 2016, two founders showed up with a product spec written on a single sheet of A4. They were non-technical, sharp, and they wanted to build a two-sided tutoring marketplace across the United States. They didn't have a CTO. For the next nine years, I was it — without the title.
That's the role I want to talk about, because it's the one most companies don't know how to ask for.
HeyTutor never had a CTO on the org chart until 2023. They didn't need one, because they had me. I owned the architecture, the infrastructure, the CI/CD, the database, the server management, the API selection, the hiring, and the technical roadmap. Operational ownership, not advice from the sidelines.
People hear "fractional CTO" or "technical advisor" and picture someone who drops in for a strategy call and disappears. That's not what this was. I was scaling load balancers late at night when traffic spiked. I was in the schema design, the query optimization, the migration planning. The database decisions I made in year one were still holding up the platform in year nine — which is the only real test of whether you got them right.
We turned that one-page spec into forty pages, brought in a senior designer for a full InVision prototype, and built V1 from zero. The stack was Vue on the front end — an early bet in 2016, when Vue was still proving itself — and Laravel with PostgreSQL behind a RESTful API. Stripe for payments. Real-time messaging. CI/CD with proper QA and staging environments from day one.
Marketplaces are one of the hardest things to build well, because every page has to serve two sides at once. The piece I'm proudest of is the matching engine. Over a hundred signals fed into pairing a student with a tutor: subject and grade level, teaching style, availability windows, timezone compatibility, location proximity, price range, ratings, background-check status, response-time patterns. Get the weighting wrong and the marketplace feels broken even when every individual feature works.
Timezone-aware scheduling was its own quiet monster. A student in New York and a tutor in Los Angeles need a slot that's correct in both their calendars, with recurring sessions, cancellations, and two people occasionally trying to book the same slot at the same instant. None of that is glamorous. All of it has to be exactly right.
We also generated thousands of local SEO landing pages — "math tutors in Los Angeles," "SAT prep near me" — programmatically, each with location-specific content. They became one of the platform's primary organic acquisition channels.
HeyTutor started B2C. Then school districts came calling, and B2B turned out to be a different animal entirely. Districts don't browse a marketplace and pick tutors one by one — they bulk-hire and assign through a CRM-driven workflow, and they need to plug into the e-learning infrastructure they already run. So we built a separate B2B layer on top of the existing platform: Google Classroom integration, district-level dashboards, bulk assignment workflows, and the compliance and reporting that government contracts demand.
That layer is what let HeyTutor win LAUSD — the largest school district in the United States. Contracts at that scale don't tolerate a platform that's flaky or undocumented. The engineering has to be right, and it has to be provably right.
Roadmaps that actually stick get built in a room. I flew our technical lead and PMs out to California to sit with the HeyTutor team in person, set the direction, and decide together what to build, what to defer, and what to kill. You can run a nine-year engagement remotely, but the inflection points — the moments where the product's direction changes — are worth being in the same room for.
In 2023, HeyTutor hired their first in-house CTO, and I handed the technical leadership over to their internal team. That's the outcome a fractional engagement should produce. The company grows until it needs and can afford a full-time technical leader, and the handoff is clean because the codebase, the infrastructure, and the processes are all documented and well-maintained. A messy handoff means you built a dependency, not a system. A clean one means you did the job.
By the end: 10,000+ tutors, 10,000+ students, tens of thousands of sessions a month, continental US coverage, multiple funding rounds, and both founders on the Forbes 30 Under 30 list. Nine years — my longest engagement, and the one I'd take again without hesitating.
If you're a non-technical founder with a hard product and no senior engineering leadership, this is the gap I fill: someone who owns the technical reality of the company end to end, builds the team, makes the architecture decisions you'll be living with for years, and hands it off clean when you've outgrown the arrangement. Not a deck. The actual thing.