The Two-Hour Feature

AI can make writing code cheaper while leaving the cost of owning software unchanged.

A feature might take two hours to build, then stay with the product for years. The build estimate covers its creation. The team inherits everything that follows.

"Can we build it?" is now often easy to answer. Before approving the work, ask: "Do we want to own it?"

Shipping turns a feature into a promise.

From then on, the team must test it, secure it, explain it, support it, measure it, migrate it, and keep it compatible with everything around it. Customers learn how it works. Sales may sell it. Other code begins to depend on it.

The first version is often the cheapest part.

A build estimate records the cost of creation. It says little about the obligations that follow.

A customer asks for one setting. Another workflow needs an exception. An experiment ships without a review date.

Each choice sounds defensible on its own. Together, they turn the product into an archive of decisions nobody revisited.

Users have to understand every extra option. The test suite has to cover every extra path. The next design has to respect every promise already made.

AI-assisted development removes useful friction from creation. This helps disciplined teams move faster. It also lets undisciplined teams accumulate waste faster.

An experiment is temporary code used to answer a question. Without an expiry decision, that temporary code becomes permanent by default.

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?

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

"We can remove it later" means something only when later has a date, an owner, and a deletion path.

A roadmap should name removals alongside additions. It should also record which requests the team has decided to refuse.

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.

The idea has a name, via negativa: improve a system by removing what makes it worse.

Put subtraction on the roadmap as product work. Removing features clarifies 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. When uncertainty is high and removal is cheap, prototype with an expiry date. If the strongest argument is "it is easy to implement," refuse the request.