Last week, I got frustrated enough with the tools in front of me that I did something I probably would not have done even a year ago.

I sat down and built my own.

Not a company product or some polished platform. Just a simple application for my own use, something lightweight enough to support my work without the complexity, cost, and setup overhead that seem baked into so many tools now.

And I got to a working MVP in a few hours.

For most of my career, the path from frustration to functional software had enough friction to force a certain kind of discipline. You had to think harder up front because the cost of getting it wrong was higher. You could not casually move from "this tool annoys me" to "I built my own tool over my morning coffee."

Now you can. That is real, and it matters.

But after the first version worked, I ran into something more interesting: the hard part started.

Working is not the same as done

The MVP worked well enough to feel real. I could use it, see its shape, and immediately see where it was falling short. I started taking notes for the next iteration right away, which made sense.

Then I caught myself doing something else.

Before I had even fixed the obvious gaps in the first version, I was already thinking about what else I could add. New capabilities, better workflows, more powerful features. Ideas that would make it more useful, more complete, more impressive.

I did not even have the MVP really working yet, and I was already drifting into expansion.

That is not a new mistake. But AI makes it much easier to commit. When the cost of building drops this far, adding the next thing starts to feel almost free. The danger is that expansion begins to feel like progress, even when you have not learned enough from the current version to justify it.

The bigger surprise was not scope creep

The more interesting realization was not that I was tempted to add features too early. It was that I had started building in a way that bypassed my own judgment about what I was actually trying to solve.

While I had a clear view of the problem, I did not begin with a well-defined, worked-out picture of what a solution would look like. I did not think carefully about the most important use cases or what the first version needed to prove before I moved on. I started from frustration and momentum. I had a problem, a rough idea, and tools that made action cheap enough that I could skip past all of that and go straight into building.

That is part of what makes this moment real. It is also where the risk lives.

I am not arguing for long briefs or slower cycles. Some of that friction deserved to disappear. But it would be a mistake to assume that because the old process can collapse, judgment can collapse with it.

AI changes the form of discipline, not the need for it

The real shift is this: AI does not remove the need for judgment. It removes some of the friction that used to force it, and those are very different problems.

In the past, the mechanics of building often created discipline by default. When building was slower and more expensive, you were more likely to pause, frame the problem, and define what success looked like before anything got built.

Now the tools let you move earlier. Sometimes that is exactly what you should do. A fast prototype can create learning you would not get from another meeting or another document. But speed changes the burden. The question is no longer whether to preserve the old process. The question is where judgment still needs to show up, deliberately, in a world where building is no longer the main constraint.

That might mean being clearer about what the first version is supposed to teach you. It might mean making more conscious decisions about when to stay with what you have and when to expand. It might mean resisting the very human temptation to mistake possibility for progress.

The point is not to slow everything down. The point is to know where to slow down just enough that speed does not turn into waste.

Judgment has moved closer to the build loop

AI is blurring the old boundary between people who define things and people who build them. Builders are making more product decisions in real time. The loop between framing and execution is tighter than it used to be, and that boundary is unlikely to come back.

Which means judgment can no longer live only at the front of the process, in a document or a planning meeting, before the work starts. It has to live inside the loop itself, in the moment when you are deciding whether to fix what you have or add the next thing.

What I took away

I am glad I built the MVP the way I did. It gave me something real to react to very quickly, and that matters.

But it also reminded me that when building becomes this accessible, anyone doing serious work with these tools needs to be more deliberate about where judgment enters the process. The risk in an AI world is not only that we build the wrong thing faster. It is that we stop noticing the moments when real thinking still has to happen, and those moments are what still determine whether speed becomes learning or just drift.