The First 90 Days

"The secret of getting ahead is getting started."
— Mark Twain

I almost didn't write this chapter.

The rest of the book is observation — here's what I see happening, here's the pattern, here's what the people who are building have in common. This chapter has to be different. This chapter has to answer the question that observation alone doesn't address: what do I actually do?

And the honest answer is messy. The first 90 days of building something don't look like a process. They look like a series of small, uncertain moves that only make sense in retrospect. I've watched enough people go through it to know that the ones who succeed and the ones who don't are not distinguished by their plan. They're distinguished by whether they kept moving when the plan stopped working.

So this isn't a plan. It's a description of what I've watched work, and what I've watched fail, in the first 90 days of people building something of their own.

The first thing that works is specificity. I covered this in the chapter on niches, but it matters again here, because the most common failure mode in the first 90 days is starting too broad.

I've seen someone spend six weeks building a "productivity platform for professionals." By the time they had something to show, they couldn't explain who it was for. Professionals? Which ones? Doing what? With what existing tools? The product tried to do everything and therefore did nothing particularly well for anyone in particular.

I've seen someone else spend one week talking to twelve physical therapists about their scheduling frustrations. By day ten, she had a prototype. By day twenty, she had three paying users. By day ninety, she had forty-two. The difference wasn't talent or resources. It was that she started with a person and a problem, not a category and an ambition.

The specific move is this: before you build anything, identify one person you know — or can reach — who has a problem you understand. Talk to them. Not a survey. A conversation. Ask them what frustrates them about a specific part of their work. Listen for the thing they describe with energy — the thing that's not just mildly annoying but genuinely wastes their time or money. That thing is your starting point.

Not your market. Not your business model. Your starting point.

The second thing that works is building something ugly, fast.

I struggle with this one myself. I like things to be well-made. There's a part of me that doesn't want to show anyone something unfinished. But the data is unambiguous: the builders who iterate from real feedback outperform the ones who polish in isolation, and it's not close.

The reason is that you don't know enough yet to make the right thing. You know enough to make a thing — something that addresses the problem you heard about in those conversations. But you don't know which parts of your solution matter and which parts don't. You don't know which features people will actually use and which they'll ignore. You don't know what they'll pay for versus what they'll consider nice-to-have. The only way to find out is to put something in front of them.

With today's tools, a prototype takes days, not months. I'm not speaking theoretically — I've watched non-technical people build working web applications using AI coding assistants in a weekend. The applications weren't beautiful. They worked. They solved a real problem for a real person. And the feedback from that real person was worth more than any amount of additional development time.

The specific move: take the problem from your conversations, build the simplest possible version of a solution, and show it to the people you talked to. Not a pitch. Not a demo with slides. Just: "I made this thing based on what you told me. Does it help?"

The third thing that works is charging money immediately.

This is the one that surprises people the most, and the one I feel most strongly about. The instinct is to offer the early version for free — to build goodwill, to gather feedback without the friction of payment, to wait until the product is "ready" before asking for money.

That instinct is wrong, and here's why: money is the only honest signal.

When someone uses your product for free, they're giving you their attention. Attention is abundant and cheap. They might use it for five minutes, tell you it's great, and never open it again. The feedback you get from free users is contaminated by politeness and low stakes.

When someone pays for your product — even a small amount — they're telling you something real. They're saying: this problem is painful enough that I will exchange money to make it go away. That signal is worth more than any amount of user research, because it demonstrates actual willingness to pay, which is the only thing a business ultimately runs on.

The amount doesn't have to be large. Some of the most successful early-stage builders I know started with pricing that was almost certainly too low — $10 a month, $29 one-time. The point wasn't to maximize revenue. The point was to establish the habit of the transaction, to get the signal that real value was being exchanged, and to learn what price point people accepted without hesitation.

Sarah — the healthcare referral tool builder from an earlier chapter — charged $99 per month from her second user onward. She was nervous about it. Her first user had been free, and the product was rough. But her second user paid without negotiating, and told her she was probably charging too little. That single data point reoriented her entire approach.

The fourth thing that works is telling people what you're doing.

This isn't content marketing. It isn't social media strategy. It's simpler than that: when you're building something, tell the people in your life what you're building. Tell them on Twitter or LinkedIn if you're comfortable there. Tell them in the Slack communities where your niche gathers. Tell them in person, over coffee, at industry events.

I know a guy who built a successful tutoring scheduling tool for music teachers. His initial distribution strategy was posting in three Facebook groups where music teachers discussed business operations. He didn't pitch. He shared: "I'm building a scheduling tool specifically for music teachers because the generic ones don't handle recurring lessons well. Here's what it looks like so far. Anyone want to try it?"

Twelve people raised their hands. Four became paying users. One of them moderated the group and started mentioning it to people who asked scheduling questions. Within three months, the tool had fifty users, all from organic referrals within communities the founder was already part of.

That's not a marketing strategy. It's participation. And it works because people who see you building something for their community want you to succeed.

Here's what the timeline actually looks like for most people who make it work.

Weeks 1-2: Conversations. You talk to 10-15 people in your target niche. You listen more than you talk. You come away with a clear problem statement — not a business plan, a problem statement. One sentence: "[Specific type of person] spends [X hours/dollars] dealing with [specific problem] because [reason the current solutions don't work]."

Weeks 3-4: Prototype. You build the simplest version that addresses the core of the problem. If you're technical, you code it. If you're not, you use AI tools. If the problem doesn't require software, you build a service offering — a process, a template, a consulting framework. The output is something tangible that you can show to the people you talked to.

Weeks 5-8: First users. You go back to the people from your initial conversations and ask them to try it. You charge money, even if the amount feels uncomfortably low. You watch how they use it. You ask what's missing. You notice what they use that you didn't expect them to use. You fix the things that break. You add the things they need.

Weeks 9-12: Iteration and distribution. Your product is better now — not because you polished it in isolation, but because real users shaped it. You start telling people about it. You write about what you're learning. You participate in the communities where your users gather. New users start arriving not because of marketing, but because your existing users mention you when someone describes the problem you solve.

By the end of 90 days, you have three things: a product that works well enough to charge for, a small group of paying users who give you real feedback, and an emerging understanding of what this business could become.

You don't have a finished product. You don't have a business plan. You don't have everything figured out. What you have is something real — something that exists in the world, that people pay for, that you own.

I want to be honest about what the first 90 days also include, because the narrative of building can make it sound smoother than it is.

There will be a week — probably around week three or four — when you wonder if this was a mistake. The prototype isn't working the way you imagined. The conversations didn't yield the clarity you hoped for. The problem you identified turns out to be more complicated than you thought, or less painful, or different from what you assumed.

This is normal. I've watched it happen to nearly everyone. The people who get through it are not the ones who feel confident. They're the ones who keep building despite not feeling confident. The market hasn't rejected them. They've just encountered the gap between what they imagined and what's actually needed, and that gap is information, not failure.

There will also be a moment — sometimes in week five, sometimes in week ten — when something clicks. A user says something that reframes the entire product. A feature you built as an afterthought turns out to be the thing people actually want. Your understanding of the problem shifts, and suddenly you see the business you're building more clearly than you did when you started.

That moment cannot be planned for. It can only be reached by building.

I'll end this book the way I've been trying to write it: not with a conclusion, but with an observation.

The people I know who are building things right now — the ones who moved, who started, who put something real into the world — are not the most talented people I know. Some of them are extremely talented. Some are ordinary. What distinguishes them is not capability. It's orientation.

They look at the current moment and see not just what's being taken away, but what's being made available. They see the tools. They see the access. They see the window. And they move toward it, imperfectly, uncertainly, but consistently.

Something is happening. That much is clear. What isn't clear — what can't be clear yet — is what the world looks like on the other side of this transition. But the people who will have the best view from there are the ones who are building something now.

Not planning. Not researching. Not waiting for the right moment or the right idea or the right set of circumstances.

Building.

The tools are here. The barriers are gone. The window is open.

The only remaining question is yours.

This is the end of The Great Transition. But it's the beginning of whatever you decide to build.