The bottleneck moved
For most of software's history, code was the scarce part. It was expensive, so if you could build, you had an advantage, and business models were shaped around that. Agencies charged for it, startups raised money for it, and "technical co-founder" was the most wanted role in the startup world.
Now a working first version can appear the same afternoon you describe it. App stores and launch platforms fill up with new AI products every week, and most are gone within months, plenty of them fast and polished.
This has happened before. In 1888 Kodak sold a camera with the slogan "You press the button, we do the rest", and photography stopped needing a darkroom. Over a century later the smartphone put a good camera in every pocket. Both times the world filled with photographs and very few of them were great. The scarce skill moved from working the camera to knowing what to point it at.
Why it's easy to keep building anyway
Building feels like progress. You end the day with a screen you can show people. Talking to customers is awkward and slow, and a sharper positioning sentence doesn't feel like a day's work even when it's worth more than a month of code. So people build first and plan to "see" later, and the seeing rarely happens. A product launched into silence teaches you very little, because you can't tell whether the idea, the description or the reach was wrong.
I do this too. In the twelve months before I wrote the book, I built more than twenty apps with AI and released two. Most were weekend experiments, and I dropped them early. A few started as serious ideas and died the same way as the toys, because when building is this easy, it becomes a way to avoid deciding.
Flip the ratio
The old process was roughly a month working out what to build, six months building, then launch and hope. Now the build can take a week or two. Most people keep the old order and just finish sooner, which mostly means more launches nobody notices.
The better move is to spend most of the time on what decides the outcome: picking the problem, talking to people who have it, getting the description right and planning how to reach them. Then build in a short sprint at the end. The total time is about the same, and the odds are much better.
Smaller problems are worth solving now
When a product took six months and a team, the problem had to be big. That left a lot alone: trades too small for a funded company, jobs still done in spreadsheets, services sold by the hour that could be a product. A few hundred people in one trade paying a small monthly price is a side income, and a couple of thousand is a salary. One person can build for that now.
A designer friend of mine built an app in Hong Kong in 2010 that turned English addresses into Cantonese, so you could show the taxi driver your phone instead of trying to pronounce the street. Expats and tourists ran into the problem daily, word spread, and it sat in the top ten of Hong Kong's travel category for years.
Who does well now
Being the best builder no longer decides who wins. The people who do well combine decent building skills with good judgment about problems and people. If you come from the non-technical side, your understanding of customers, an industry or what looks right is now the half that sets you apart, and the other half is within reach. If you're technical, building still matters, but it isn't enough on its own anymore.
A short pause before you build is where most of the advantage is. A few days checking that the problem is real and that someone would pay to have it solved. The five-question filter is a quick first pass, and which race are you in? helps you work out how much the product needs to earn.
Related
- The five-question filter, five questions to run a problem through before you build
- Which race are you in?, side product, new venture or credibility play
Based on chapter 1, "Anyone can build now" of The Code Was Never the Hard Part.
