The Second Price

The new thing looks cheap.

That is the trap.

A customer asks for one small exception. A feature needs one extra setting. A new tool promises to save a few hours. You can see the work in front of you, so you price that work and say yes.

Then the second bill arrives.

The exception has to be remembered. The setting has to be tested. The tool has to be renewed, watched, taught, fixed, and explained to the next person. None of this looked expensive at the moment of choice. Most of it did not look like a choice at all.

You are probably not bad at estimating. You are estimating the wrong thing. The first price is what it takes to add something. The second price is what it takes to keep living with it.

The Cheap Part Comes First

New work arrives dressed as a moment. Build this page. Add this field. Make this report. Give this client a special rule. Moments are easy to inspect. They have a start, an end, and a satisfying little finish line.

Carrying work has no such theater. It hides in every week after launch. It appears when the old field breaks the new form, when the special rule collides with a standard process, or when someone asks why the report disagrees with the dashboard.

This is why a business can keep shipping and still feel slower each month. The team is not merely doing new work. It is carrying every old yes that still demands memory, judgment, or care.

Martin Fowler's explanation of technical debt is useful here because it separates the fast move from the later interest it creates. A quick design choice can help you ship now, but the extra effort appears each time you work around that choice later.

The same shape exists outside code. A custom promise creates service debt. A clever workaround creates memory debt. A new channel creates attention debt. A tool bought for one task creates another system that now expects an owner.

The purchase is visible. The possession is not.

Growth Can Hide the Bill

At first, the carrying cost feels harmless. You know the odd rule. You remember which client gets the extra step. You can fix the fragile automation in five minutes because you built it.

That private fluency is dangerous. It makes a weak system feel cheap because the cost is being paid from your memory.

Then volume rises. Someone else touches the work. You take a day off. The five-minute fix becomes an hour of diagnosis because the useful context never left your head. What looked like speed was a loan from your future attention.

The operational guidance in the AWS Well-Architected Framework treats operations as something that must be understood, improved, and prepared for failure. That matters far beyond cloud systems. If a new thing cannot be observed, owned, and repaired, the launch did not finish the work. It only moved the work out of sight for a while.

This is the secret fear under the pile. If you count the second price, some exciting ideas stop looking exciting. Some generous promises stop looking generous. They look like permanent claims on a person who is already tired.

So you keep the accounting narrow. You ask, "Can we build it?" That question protects the thrill of adding. The harder question is, "Do we want to carry it?"

Small Scope Can Still Be Heavy

A tiny request can create a long tail. One custom export may touch support, onboarding, documentation, permissions, billing, and every future change to the data underneath it.

Size at birth tells you almost nothing about weight in use. A small feature used everywhere can demand more care than a large feature with one clean owner.

The Shape Up method from 37signals makes a related distinction between the amount of time a team is willing to spend and a fixed estimate of everything a solution might require. The appetite creates a boundary, then the scope must fit inside it on purpose.

That boundary should survive launch. It is not enough to cap the build while leaving the care unlimited.

Your objection is reasonable: some bets cannot be understood before they exist. True. The answer is not perfect foresight. The answer is to stop pretending that uncertainty makes future cost equal to zero.

Price the Carry

Before the next yes, run a Carry Test. Start with ownership. Name the person who will notice when the new thing fails, answer questions about it, and decide when it should change. If the answer is everybody, the answer is nobody with extra meetings.

Then name the recurring touch. What must be checked, renewed, updated, taught, reconciled, or remembered after the launch? Do not accept "almost nothing." Name the action and the rhythm.

Next, price the collision. What existing process becomes harder because this thing now exists? The honest cost of a special case is rarely the special case itself. It is the branching it forces everywhere else.

Finally, write the exit. Decide what evidence would make you remove the feature, end the exception, leave the channel, or cancel the tool. A thing with no exit rule is not a test. It is a quiet inheritance.

This does not mean you stop adding. It means every addition has to earn both its birth and its upkeep.

The Business Gets Lighter

Imagine the next request arriving. The same small favor. The same easy build. The same warm urge to be helpful.

This time, you look past the launch. You see the owner, the recurring touch, the collision, and the exit. You may still say yes. But it will be a clean yes, paid for with open eyes.

Or you may cut the feature, standardize the promise, or remove an old exception before adding a new one. Nothing dramatic happens. That is the point. The business simply stops getting heavier in places nobody chose.

The first price asks whether you can afford to begin. The second asks whether the future can afford to keep it.

Pay attention to the second one.