when everything becomes buildable
AI has shrunk the distance between an idea and a working demo to almost nothing, which makes it very easy to end up with a pile of half-built projects. This piece is about choosing which ones to carry through, and why getting version one in front of people is the best use of the head start these tools give us. — Ryan Mish
As featured in Runpoint Magazine.
It’s never been easier to build something you’ll never finish. You get a mock-up working, click around in it, and it already feels almost done. Then the ideas start: if it can handle this one task, it could handle the whole workflow around it, and before long the plan has outgrown the problem you set out to solve. Each improvement makes the project more compelling, even as the person who could benefit from it has to wait a little longer.
The familiar warning about making the perfect the enemy of the good doesn’t quite describe what happens to the mock-up. Perfectionism keeps refining what’s already there, while the mock-up keeps stretching toward something bigger than the original goal. Expansion can keep a useful solution out of reach just as effectively. The challenge is recognizing when a good idea belongs in the next version rather than becoming another condition for finishing this one.
AI makes this especially tempting because the time between having an idea and seeing it work has become so much shorter. We can explore possibilities that would once have been too expensive even to consider, and people who understand a business problem can participate directly in building its solution. That’s an extraordinary opportunity, although it leaves us with a question that used to be partly answered by our limitations: with so much now within reach, what is worth carrying through?
Choosing what to carry through matters more now than it will later. In the next five years, custom software, agents, and personalized experiences will be ordinary business infrastructure, and simply having them won’t set anyone apart. What will set a business apart is how it uses the years in between. One that spends them getting faster and better at serving its customers builds a lead that a competitor who waited can’t claw back. Everyone will have these tools eventually. How far will your business have grown by the time they do?
A working demo can make it seem like everything is worth it. Once we’ve watched software handle a task, we’re already picturing the time it will save someone. The satisfaction arrives before we’ve dealt with the less exciting work of getting it into their hands and finding out whether they’ll actually use it. It’s a kind of mirage: a convincing glimpse of an improvement that still requires considerably more effort to reach. Starting another project offers that satisfying glimpse again, that rush of dopamine, without requiring us to finish the first. Nine promising tools can feel like more progress than one useful tool, especially when the building is fun.
The more useful question for any project is what it would let the business do that it can’t do well today. That might mean improving a customer experience or replacing a system people spend too much time working around, and the most valuable change often looks pretty ordinary to anyone outside the business. What matters is being specific about whose work will improve and how, so there’s some way to judge success beyond the fact that the thing got built.
Technical teams have their own version of getting absorbed in the possibilities. A working backend invites a refactor; a tool could be more elegant in a different form; projects that were separate might belong together after all. Some of these changes are essential before a release, and nobody should rush past unreliable calculations or inadequate permissions. The harder judgment concerns improvements that would make the system better but don’t need to happen before someone can benefit from it. Once a tool is reliable enough to use, getting it into people’s hands is usually worth more than holding it back for cleanup, especially when the next model release may be able to handle that refactor overnight.
Clear requirements are what make a project “finishable”. When everyone agrees on the outcome, it’s possible to define a first release that lets someone do one meaningful piece of work, with whatever safeguards that work needs, and to park new ideas for a later phase without reopening every decision. Reaching that release quickly matters because people use software differently from how they review it. Someone with a job to get done will run into problems nobody spotted in a demo, and in larger organizations much of that feedback arrives just before launch, when the date finally makes the software real and people start paying close attention.
The right pace still depends on your culture and the people involved. Phased releases work well when a team wants the change and has the capacity and support to learn as it goes. A business with demanding stability requirements or regulated processes may need more validation and fewer releases without being any less serious about improvement, and nobody should have to relearn their tools every few days.
There will always be a better version to imagine, but there’s time for better once version one is built. The only reliable way to learn which improvements deserve the effort is to put it in front of end users as soon as it can do the job. Each release settles questions that endless mock-ups couldn’t answer, so the next release becomes easier to choose and faster to build. That’s how a business accelerates while these tools are still new and builds momentum that lasts. When almost anything is buildable, we can’t afford to spend our head start on something that never launches.