
Scope Discipline When Building Is Cheap
Engineering cost used to do your prioritization for you. It stopped. Deciding what not to ship is now the only constraint holding a product together.
For most of my career, cost did the deciding. A feature was three weeks of somebody's time, so it had to be argued for, and the argument killed most of the bad ideas before anyone typed anything. Nobody had to be especially disciplined. The roadmap was rationed by scarcity.
That rationing is gone. The feature is an afternoon now, sometimes an hour. Sure, why not has become a viable answer to almost any request, and it is quietly wrecking products.
The Bill You Still Get
Build time was never the real price of a feature. It was the part you could see.
The real price is surface area. Every feature is another state to hold in your head, another thing to explain, another place for a bug to live, another decision handed to somebody who came here to do one specific thing. It is a permanent obligation to keep working while everything around it changes. None of that got cheaper. Generation collapsed the one cost that was visible and left every invisible cost exactly where it was.
So the ratio inverted. It used to be expensive to build and easy to keep a product coherent, because you could not afford enough features to make it incoherent. Now it is cheap to build and expensive to stay coherent.
The Deletion List Should Be Longer
On Fire Lion, the game I shipped solo, the list of things I cut ended up longer than the list of things I kept. That is not a confession. That is the correct ratio, and I would be suspicious of any product where it goes the other way now.
Ring-Rival is the sharper example because I can put a number on it. Time from tapping the link to throwing your first punch was twenty-two seconds. It is six now. I did not optimize anything. I deleted the splash screen, the mode select, the fighter select, and the tutorial.
Every one of those was a correct answer to a reasonable request. Mode select is standard. Onboarding is standard. What made them wrong was this specific product: a browser game somebody opens from a link with about fifteen seconds of curiosity attached. Every screen before the punch spends that budget on something that is not the punch.
No model was ever going to propose that, and I do not hold it against them. Nothing in the request said the interesting thing about this product is how fast you get hit.
Reasonable Is the Trap
Ask a model for a settings page and you get a good settings page. Ask for notification preferences, an onboarding flow, an empty state with a call to action, and each one comes back competent and defensible. Every single addition is reasonable in isolation.
Products do not die of one unreasonable feature. They die of forty reasonable ones, each of which had a fine justification, arriving faster than anyone can evaluate whether the thing still has a shape. When the cost of a wrong yes was three weeks, you noticed. At an hour, you do not.
This is the same problem as generating fifty design variations and picking the one that stands out rather than the one that is right. It is why taste turned into the whole job the moment production stopped being the bottleneck.
What I Do Instead
I set a budget that is not measured in time, because time no longer constrains anything. Screens before the core action. Decisions asked of the user in the first minute. Items in the main navigation. Those are the numbers I hold fixed. New thing goes in, old thing comes out.
And I ask two questions before anything gets built. What does this take away? Attention, speed, clarity, the ability to explain the product in a sentence. And is this worth being in the first five seconds, because everything visible on arrival is competing for the same fixed budget of patience.
If a feature only survives on the grounds that it was easy to build, that is not a reason. That is the absence of one.
Deleting After You Ship Got Easier
The one genuine gift here is that sunk cost mostly evaporated. I used to fight to keep things that had consumed a month of team time, because removing them felt like admitting waste and someone had to sit through that conversation.
A feature that cost an afternoon is not hard to let go of. It cost an afternoon. And if I turn out to be wrong about cutting it, rebuilding it costs another afternoon.
That is the actual superpower in the current moment, and it is not the speed of building. It is that being wrong stopped being expensive, which means you can afford to be much more aggressive about what you refuse to keep.
Related AI Design Posts

When Generating Is Free, Taste Is the Whole Job
Producing options was never the bottleneck. Ring-Rival got good because I deleted things a model would have been happy to keep building.

The Work Is Deleting, Not Generating
AI made producing screens almost free. That moved the bottleneck from making things to deciding which ones to throw away, and no model will do that part for you.

The Demo Works. Shipping Is a Different Job.
A demo is the happy path with data you chose. Everything that made my products hard was in the part nobody demos: dates, permissions, empty screens, and the jobs that run while you sleep.