Do Your Homework

Almost every single one was about the wrong thing. The questions kept coming, dozens of them, and I could feel the pattern before I could name it. How do you get your app to production quality? How do you handle distribution? What's the best way to monetize a vibe coded product? Is it even possible to build something reliable enough to sell? Reasonable questions, the kind any serious builder eventually needs to answer, but they're also the questions you ask at the end of a very long road, and everyone in that room was standing at the beginning.

A Sunday morning in a coworking space in Lisbon, nearly a hundred people in the room, and I was supposed to talk for five minutes. A quick overview of what I've been building, what I've learned, some observations from the past year of vibe coding every single day. Five minutes came and went, and then ten, and then fifteen, because the questions wouldn't stop. I mentioned, almost as an aside, that I've been consuming roughly a billion tokens a week across every tool I can get my hands on, Lovable, Cursor, Replit, Claude Code, Codex, and a handful of others whose names have already blurred together. The room changed. People sat up. Hands went up before I finished my sentence. What had been a polite audience listening to a short talk became something closer to an intervention, dozens of people who had been sitting with their own frustrations suddenly realizing someone in the room might have answers.

There was a person near the front who was clearly frustrated with the whole endeavor. They'd been building something, trying to turn it into a product, hitting the wall that every vibe coder hits when they move from prototype to production. The bugs that multiply. The features that almost work. The gap between what the AI delivers and what a paying customer would accept. They wanted to know how to close that gap, and the honest answer was that they were asking the question three stages too early.

I ran a software company for fifteen years and studied software engineering. I understand what production-level software needs, the infrastructure, the testing, the reliability, the thousand invisible decisions that separate a prototype from a product people trust. And what was striking to me in that room was the assumption that AI had collapsed all of that into a few prompts. That you could describe your dream in plain language and have it arrive, production-ready, on the other side.

That's not how any of this works. Not yet. Maybe not ever, at least not the way people imagine.

What I told the room, and what turned the five-minute demo into a fifteen-minute conversation, was something that felt almost too simple to say out loud. There's a progression to this, and most people are trying to skip to the end.

The way I think about it now, after a year of building every single day, is that there are three phases. The first is building for practice. Throwaway things. Apps and tools and experiments that you will never open again. The purpose isn't the output, it's the learning. Understanding what the tools can do, how the back and forth with an AI actually works, where the models are strong and where they hallucinate with extraordinary confidence. I have hundreds of these, scattered across platforms, most of them abandoned within hours of creation. They were never meant to last. They were meant to teach me something, and they did.

The second phase is building for yourself. A personal productivity tool, a workflow automation, a scheduling assistant, something that you yourself need and will actually use. Not theoretically use. Use tomorrow morning. Use next week. Use next month. This is where most people discover how hard building actually is, because the standard is no longer "does it work once," it's "will I reach for this again." I've built dozens of tools for myself that I used for a single day and then abandoned, because the experience wasn't good enough. A button in the wrong place. A flow that required three clicks when it should require one. The kind of friction that's invisible when you're building and unbearable when you're using. That friction is the curriculum. Working through it, iterating on the small annoyances, staying with something long enough to make it genuinely useful to yourself, that's where the real skill develops.

The third phase is building for others. Products to sell, tools to share, things that need to be stable and reliable and worth someone's money or attention. Distribution, monetization, go-to-market, all the questions that room was asking. Production-level software has always been hard, and AI hasn't changed that. It's changed who can attempt it. It hasn't changed what it demands.

The thing I keep circling back to is why most people try to jump straight to phase three. And I think the answer is something that has very little to do with technology.

There was a moment during the Q&A where I challenged someone directly. They were frustrated with the gap between their prototype and a sellable product. I said, build something you yourself will use every day for thirty days. Not for someone else. For you. Wake up tomorrow and use it. Use it again the next day. If you're still using it after a month, come back and talk to me about monetization. The look on their face suggested this was not the advice they were hoping for.

Because it sounds like homework. And adults, particularly adults in our thirties, forties, and fifties, have forgotten how to do homework.

We've spent our professional lives optimizing for results. For ROI. For the most efficient path between effort and outcome. In the world we were trained for, doing something without a clear return on investment feels wasteful, almost irresponsible. The idea of building something you'll never look at again, on purpose, as practice, runs against every instinct that Western capitalist culture has spent decades installing in us. Everything must produce. Everything must count. Everything must be monetizable.

If I said this to a twenty-year-old, they'd get it immediately. They're still fluent in the language of learning for its own sake. It's called practice. It's called training. It's the thing you do before the thing you do matters. Somewhere between twenty and forty, we lose that fluency. We start believing that effort without visible output is wasted effort. And then we sit in a room at an AI event and ask how to monetize an app we haven't even built for ourselves yet.

Professional athletes still practice. That's the part that gets me. LeBron James, in his twenty-second NBA season, still practices. Every single day. Not because he doesn't know how to play basketball, but because the practice is what keeps the game sharp. Before he was in the NBA, he was in high school, playing games that didn't count for anything except his own development. Before that, he was in a driveway. The progression from driveway to practice court to professional arena is so obvious in sports that we don't even question it. Nobody watches a kid shooting hoops and asks about their distribution strategy.

But with AI building, which is genuinely new, which none of us have been doing for more than a couple of years, we somehow expect to skip the driveway and the practice court entirely. We want to walk onto the professional court because the tools feel professional. The interface is so good that it tricks us into thinking we should be producing professional output. The AI doesn't care that it's your first week. It will confidently attempt whatever you ask. And that confidence is contagious in a dangerous way, because it makes you believe that the gap between you and a shipped product is smaller than it actually is.

I've been thinking about what the next twelve months look like for people entering this space, and I keep coming back to the idea that the biggest barrier isn't technical. It's cultural. It's the deeply internalized belief that learning without producing is a luxury we can't afford. That building something we'll never show anyone is a waste of time. That the only valid reason to sit down and create is if the creation has a market.

The people I know who are getting genuinely good at this, the ones whose work is starting to feel solid and intentional and useful, are the ones who gave themselves permission to be bad at it for a while. Who built throwaway things without guilt. Who spent weeks on a personal tool that only they would ever see, not because they were building a product, but because they were building a skill. The skill is the product. Everything else comes after.

I spent a year doing my homework. A billion tokens a week, hundreds of abandoned projects, thousands of hours of the particular frustration that comes from watching an AI agent confidently declare a bug fixed while the app is visibly on fire. There was just a person learning, slowly and expensively and often at 4am, how to build things that actually work.

The room at that event wanted the shortcut. I understand the impulse. But the shortcut doesn't exist, not because the tools aren't powerful enough, but because the person using them needs time to develop judgment that no model can provide. When to push forward and when to start over. What good enough actually looks like. Which features matter and which ones are noise. That judgment is what separates a prototype from a product, and it's built the same way every durable skill has always been built.

One throwaway project at a time. One tool you use yourself until you can't stand the rough edges. One month of daily use before you ask anyone else to care.

Build something tomorrow. Something small, something useless, something you will never show another person. See if you can tolerate how that feels. The discomfort of making something that doesn't count. If you can sit with that, you're closer to ready than everyone in that room asking about distribution and monetization.

The tools have been ready for a while now. The homework is yours.