The Student Who Pays the Tutor
A few years back, I shipped a little flashcard app called SnapDecks. The idea was simple: take a picture of a page of notes, and it would turn the text into a deck of study cards. I thought the buyer was a student cramming for a final. I was wrong. The people who actually paid were their parents.
The Accountability Gap
When you’re building educational tools, it’s easy to get this wrong. You build for the user—the student—but the buyer is often someone else. A teacher, a school administrator, a department head. Or in the case of my flashcard app, a parent who just wanted their kid to pass biology.
This creates a weird tension. The user wants something fast and easy. The buyer wants a result. They want proof of learning, better grades, a measurable skill. They’re buying an outcome, not just a tool. If the tool is fun to use but the grades don’t improve, the buyer churns. And they’re the one with the credit card.
For a long time, this was the standard model for a lot of educational software. You sell to the institution or the parent, and the student is just the person who has to use it. The buyer is accountable for the outcome, so they get the final say. But that’s starting to feel like an old map for a new territory.
The New Buyer on the Block
Lately, I'm seeing a different kind of person show up in my support inbox for apps like SnapDecks and another one I built for code snippets. It’s not a student, and it’s not a parent. It’s a professional—a designer, a marketer, a project manager, a junior developer—who is using their own money to learn a new skill they need for work right now.
This isn't about getting a degree or a formal certification. It's about surviving next week's sprint. A project manager needs to learn just enough about API calls to have a sane conversation with the engineering team. A graphic designer needs to understand how to write prompts for an image model to keep their job. They aren't trying to become experts; they're trying to stay relevant.
They're buying learning tools for themselves because their company’s official training program is six months behind reality. The skills they need are expiring faster than any corporate learning department can create a course. So they go out and find their own tools. They become the user, the buyer, and the person accountable for the results, all rolled into one.
From Memorization to Application
This new buyer doesn't care about course completion certificates. They don’t want to watch hours of video lectures. They want to do the thing. Their metric for success isn't a score on a quiz; it's whether they could solve the problem they were stuck on this morning.
This changes how you have to think about building a learning tool. My old flashcard app was built for memorization. You cram facts, you regurgitate them on a test, and then you probably forget them. That works when the goal is to pass an exam. It doesn’t work when the goal is to apply a skill under pressure.
For this new buyer, the learning has to be tied directly to the work. It’s not about abstract knowledge. It's about practical capability. Can this tool help me build a better spreadsheet, write a clearer report, or debug a piece of code faster? If the answer is yes, they'll pay. If it's just another library of information, they'll move on. They don't have time for theory.
This is a huge shift. Instead of building for a system that values credentials, you're building for an individual who values competence. It forces you to make things that are less about teaching and more about enabling.
It’s the difference between a textbook and a workbench. One gives you the information, the other gives you a place to use it. For a long time, we sold a lot of textbooks. Now, people are looking to buy the workbench, and they’re bringing their own projects.
The real opportunity isn't just to teach people what a hammer is. It's to help them build the house.