The Two-Hour Feature

AI has made code cheap. It has not made software cheap.

A feature can take two hours to build and years to own. The build estimate counts the first step. The product inherits every step after it.

That changes the important question from “Can we build it?” to “Do we want to own it?”

A feature is not a file. It is a promise.

Once released, it must be tested, secured, explained, supported, measured, migrated, and kept compatible with everything around it. Customers learn it. Sales may sell it. Other code begins to depend on it.

The first version is often the cheapest part.

This is why a build estimate is a poor ownership estimate. It measures creation. It omits obligation.

No team plans to make a confused product.

Bloat arrives as a setting for one customer, an exception for one workflow, and an experiment with no end date. Each choice sounds defensible alone. Together they turn a product into an archive of decisions nobody revisited.

The damage is not only technical. Every extra option asks users to think. Every extra path divides testing. Every extra promise limits the next design.

AI increases this risk because it removes useful friction from creation. A disciplined team gets faster. An undisciplined team produces waste faster.

Building to learn is valid. Calling permanent accumulation “experimentation” is not.

Before an experiment starts, write five things:

1. Question: What are we trying to learn?
2. Audience: Who will see it?
3. Evidence: What result earns a permanent place?
4. Review date: When will we decide?
5. Removal path: How will we delete it safely?

Then apply one rule:

On the review date, promote, revise, or remove the experiment. Silence means remove.

“We can remove it later” is meaningful only when later has a date, an owner, and a deletion path.

Most roadmaps list additions. A serious roadmap also lists what will be removed, merged, or refused.

Removing one weak feature can remove several hidden costs at once: one choice from the interface, one branch from the test suite, one support article, one security surface, and one constraint on future work.

This is via negativa: improve the system by removing what makes it worse.

Subtraction is not cleanup after product work. It is product work. It reveals what the product is for.

Before approving a feature, ask:

• Does it solve a repeated, valuable problem?
• Does it strengthen the product's central purpose?
• What permanent obligations does it create?
• What existing feature or workflow will it replace?
• If it is an experiment, when does it expire?

Build when the expected value deserves the lifetime obligation. Prototype when uncertainty is high and removal is cheap. Refuse when the strongest argument is only that implementation is easy.

Code is cheap.

Coherence is not.