Tutoring platform, part 2 of 2
Learn the minimum, use it right away
Starting with a guess and being wrong quickly beat preparing to be right.
Context
After the first version failed, I changed how I was learning, not just what I was building.
The problem
I didn’t have time to understand everything before acting. The start of my first semester hadn’t moved. But my habit had always been to understand a subject fully and then execute, and that habit had just produced a platform nobody wanted to use.
What I did
Start from a guess
I started from one question: what is the smallest version of this that gives a student real value? My answer was the three things students had asked for. That became the hypothesis, and everything else had to earn its way back in.
Learn only what the next problem needs
Instead of learning web development as a subject, I broke the build into specific problems and learned only what each one required, then applied it the same day. It’s a less satisfying way to learn. It is much faster.
Ship weekly, listen anonymously
Every week I released an update to a small group of students and collected anonymous feedback. Anonymous mattered: it’s easier to tell your own tutor the truth when they won’t know it was you.
Go get users
Even with a better product, usage stayed flat. A good platform nobody has heard of is still empty. So I went after users directly: I contacted high school clubs, offered a one-month free trial, and added a referral program so existing students had a reason to bring friends.
After several months the platform was bringing in steady monthly revenue, and my working hours came back to something sustainable. It covered a large part of what I needed before college, and over the life of the business I also hired three tutors.
What I learned
In an unfamiliar field, preparing to be right is slower than starting with a guess and finding out quickly that it’s wrong. A weekly release forces you to be wrong in small, cheap pieces.
I’ve worked this way on almost everything since. When I built operating systems at JuicyBite three years later, with no engineering background, I used the same loop: smallest useful version, learn what the next problem needs, test it on real cases, repeat.