When Building Gets Cheap, Deciding Gets Expensive

A couple of years ago, getting a realistic prototype in front of a stakeholder took weeks. Wireframes, mockups, a round of comments, a handoff, another round of comments. Today my team builds interactive prototypes in real HTML, CSS and JavaScript with AI help, and our UI design cycles went from months to one or two weeks. On my own time, I built an entire financial-intelligence platform with AI coding agents.

Building got cheap. I expected everything to get faster with it.

It didn’t. The hard part didn’t shrink. It moved.

The Bottleneck Moves

There’s an old idea from operations: speed up one step of a process and the bottleneck simply moves to the next one. That is what happened to us. When building took months, building was the constraint, and everything else could hide behind it. Now the constraint is deciding. What should we build? Which of these five working versions is the right one? What are we not going to build? And who has to agree?

Economists have a version of this too. When something gets cheaper, we don’t do the same amount of it for less money. We do a lot more of it. Cheap prototypes mean more prototypes, more options on the table and more meetings to choose between them. Ten prototypes is not progress. It’s ten questions waiting for an answer.

Three Traps (I Have Fallen Into All Three)

1. It Looks Finished, So Everyone Thinks It’s Finished

A code prototype looks and feels like a real product. That’s the whole point, and it’s also the problem. Behind it there might be mock data, a button wired to nothing, a validation animation that isn’t validating anything. A stakeholder clicks through, it works, and the next question is, quite reasonably, “so why is launch months away?”

What helps: label the fake parts, visibly, inside the prototype itself. And keep a written spec next to it for everything a prototype skips: edge cases, error states, empty states, permissions, what happens when the data is wrong. Design tools are still very good at this kind of annotation. The prototype shows the happy path. The spec has to carry everything else.

2. Building the Clever Part Instead of the Valuable Part

Years ago I worked on a donations app that rounded up your card spending and gave the spare change to charity. Under the hood: bank connections, rounding logic, scheduled jobs, payments. It was easily the most interesting engineering in the product. Then processing fees pushed us to bundle the round-ups into weekly charges, and the donation caps effectively became “how much I’m happy to give each week”. The clever part had turned into a weekly direct debit.

When we talked to people who already donated regularly, they cared about other things. Finding charities that matched the causes they cared about. Getting the paperwork for their taxes. Seeing what their money actually did. None of it was about rounding. I ended up making the case to go back to that underlying problem, which is a much easier conversation before the build than after it.

Back then, building the clever part took months, which at least slowed the mistake down. Today you can build the clever part over a weekend. Cheap building doesn’t protect you from building the wrong thing. It just lets you do it faster, and more often.

3. The Builder-Leader Trap

This one is personal. I can prototype, design and write production code. When something needs to exist by Thursday, the fastest path is often me doing it myself. It’s faster this week and slower next quarter. The team didn’t learn it, I became the bottleneck, and the decisions only I could make waited while I was busy doing work other people could have done.

My rule now is simple to say and hard to follow: I own the what and the why, the team owns the how. Most of the time, when I build something myself, it should be to make a point, not to make the product. A prototype from me should end a debate, not start a dependency.

What Gets More Valuable

If hands are cheap, judgment is the expensive part. The skills that matter more now are mostly the old, unglamorous ones:

• Framing the problem so the team builds the right thing the first time.
• Saying no to good ideas so the great ones get the attention.
• Writing things down: decisions, edge cases, and what “done” means.
• Reviewing honestly, including AI-written code, which deserves the same review you would give a talented new hire who never says “I’m not sure”.
• Caring about data quality, because the fastest prototype in the world is still wrong if the data underneath it is wrong.

A Few Habits That Help

1. Before building a prototype, write the question it answers. If there is no question, don’t build it.
2. Mark prototypes as disposable, on purpose. Most of them should be thrown away once they’ve answered their question.
3. Keep a visible “not now” list. It makes saying no feel less like losing an idea and more like scheduling it.
4. Measure outcomes, not output. Prototypes, lines of code and closed tickets went up for everyone this year. That is not a result.

In Summary

A few years ago I wrote that strategy is the art of choosing what not to do. That was true when building was expensive. It’s even more true now that it isn’t.

AI gave us more hands than we know what to do with. The leaders who stand out from here will be the ones who decide well what those hands should build, and, just as importantly, what they shouldn’t.