
Everyone is building something now. An app over the weekend, a tool in an afternoon, a startup before lunch. No code, no team, no money needed. It's never been easier to make something, so everyone is making something.

And here's the part people miss. The number of builders went up. The number of users didn't.

Those are two different things, and it's easy to mix them up. Being able to build a product is not the same as having people who want it. We got a lot better at the first one and not at all at the second.

Because there are only so many people, and only so much time in the day. Building more apps doesn't create more reasons to use them. They all end up chasing the same attention, and there's never enough to go around. So we get more products than ever, and most of them just sit there empty.

It used to be that building was the hard part. That's why being able to build felt special. Now building is the easy part. The hard part is the thing it always quietly depended on: making something people actually want to use.

So the question isn't "can I build this?" anymore. Of course you can. Everyone can. The real one is the old one, and it matters more now than ever: *does anyone actually want it?*

*I wrote about why building fast can work against you here: [AI is killing most startups, and most don't realise it yet](/writing/ai-is-killing-most-startups-and-most-dont-realise-it-yet).*
</content>


It's never been easier to build something, so everyone does. But the number of builders went up and the number of users didn't. Most of what gets made just sits there empty.

Building was never the hard part


AI is the best thing to happen to founders in years. You can build in days, not months. You don't even need to know how to code. It has never been easier to make something.

And that's the problem.

AI doesn't just help you build fast. It helps you build the *wrong thing* fast. Building used to be slow and cost money, so you were forced to stop and think first. Now nothing stops you. You can spend weeks on a product, feel busy the whole time, and only find out later that you were going the wrong way from day one.

There's a second problem too, and it's a quieter one.

AI writes a lot of code, very fast. And most of the time, nobody on the team really understands it. That causes two problems.

The first is called technical debt. Think of it like a credit card for code. You take shortcuts to go fast now, but you pay for them later, with interest. The quick fixes pile up until the code becomes a pain to change.

The second is something I studied for my master's degree. It's called bus factor. The idea is simple: how many people would have to suddenly vanish before your project falls apart? (The dark joke behind the name is "get hit by a bus.") If only one person understands the code, your bus factor is one. That's risky. And if AI wrote it and nobody understands it, your bus factor is basically zero. Nobody can safely change it. Not even you.

So before you let AI build anything for you, be honest about a few questions:

- **Who is it for?** One real person, not "everyone."
- **What problem does it fix?** In their words.
- **Why now?** What changed.
- **What's the smallest version that proves it?**

And one more, now that AI is involved: **will anyone actually understand this after it's built?**

AI is like a fast car. It will get you somewhere quickly, but it won't tell you where to drive, and it won't teach you how the engine works. Use it to move fast. Just make sure a real person still understands what you're building.

*I explained the first few questions more here: [Three questions before you build any product](/writing/three-questions-before-you-build-any-product).*


AI lets you build faster than ever. But building the wrong thing fast is still building the wrong thing. And now nobody understands the code either.

AI is killing most startups, and most don't realise it yet


Most startups don't fail because the product was built badly. They fail because they built something nobody actually wanted.

There's a name for getting this right. It's called product-market fit. (That just means you've built something a real group of people want and keep coming back to. The product fits what the market needs.) It sounds fancy, but it really comes down to a few simple questions you can ask before you write a single line of code.

Before I help anyone build, I ask three things. They sound easy. But most founders can't fully answer them.

- **Who is it for?** Not "everyone." The one person who really feels this problem. The clearer you are here, the easier everything else gets.
- **What problem does it fix?** Say it the way that person would say it, not the way you'd sell it. The real problem, not the feature.
- **Why now?** What changed that makes this worth building today?

That last one trips people up. Sometimes the honest answer is "nothing yet." And trust me, it's much better to know that before you spend three months building.

Once you can answer these, everything gets clearer. You're not trying to make something for everyone anymore. You're making one useful thing for one real group of people. That's also why I'm a big fan of starting with an MVP, the smallest version people can actually use. It lets you test your answers in the real world, fast and cheap, instead of betting months of work on a guess.

Answer the questions first. Then build a small version to test them. That's how you give yourself a real shot at fit, instead of learning the hard way after everything is already built.


Most startups fail because they built something nobody wanted. These three questions help you avoid that before writing a single line of code.

Three questions before you build any product


When founders tell me their idea, it's never small. It's the big dream. Every feature. Every type of user. Every "oh, and it could also do this." I love that energy. You want a founder who dreams big. But for the first build, it's a trap.

You don't need all of it to start. You need an MVP. (MVP just means "minimum viable product," the smallest version that real people can actually use.) One real use. For one real person. Done well. Everything else can wait.

I once worked with a founder who had a huge vision. Instead of building all of it at once, we broke it into phases and started with a simple MVP. The trick was that each phase ended with something people could actually use. So after every phase, we had time to test it, see what was working, and learn from real users before adding anything new. By the end, he wasn't guessing. He was building on top of things he already knew worked.

That's the real payoff of starting small. You learn faster, you spend less, and you find out sooner if the idea even works. So start with an MVP. You can always add more later.


You don't need every feature on day one. Start with the smallest version real people can use, learn from it, then grow.

The smallest version is usually the right one


There's an old Swahili saying I like: *Haraka haraka haina baraka*. It means "hurry, hurry has no blessing." In other words, rushing causes problems.

I think about it a lot when I see founders rush to build. You have the idea. You can already see the product in your head. And writing code feels like you're getting somewhere. I get it. Building is the fun part. Doing something feels better than just thinking about it.

But here's what I've learned. Bad code is not the big mistake. You can always fix bad code. The big mistake is building the wrong thing, and building it well. You spend months making something clean and finished that nobody actually wanted. And that time? You can't get it back. For a young startup, time is everything.

The fix is simple. You don't have to slow down. Just spend the first few days on one question. Not "how do I build this?" but "what should I build, and who is it for?"

Get the *what* right before you worry about the *how*. Building fast will never save you if you're building the wrong thing.


Building fast feels productive, but building the wrong thing is the real mistake. Get the "what" right before you worry about the "how."

Writing

Got something in mind? Let's talk→