Why a small change costs two months

A client asks for something that takes ten seconds to describe. The team comes back with an estimate measured in weeks. Everyone is now annoyed: the client thinks they are being padded, the team thinks they are being doubted.

Both are reacting honestly to the same real thing. The change is small. The cost is not in the change.

A worked example

Take a request we have seen in some form on most projects: let users sign in with a phone number instead of an email address.

That is one sentence. Here is what it touches.

Registration. The form field is the easy part. But phone numbers need country codes, need normalising into one storage format, need validating per country, and need to handle the same number written five different ways.

Verification. Email verification is a link. Phone verification is an SMS, which means a provider, an account with that provider, per-message costs, delivery failures, a resend flow with rate limiting so it cannot be abused, and an expiry window.

Password recovery. The entire flow assumed an email address existed. It now needs a second path, and a decision about what happens for users who have one and not the other.

Existing users. Everyone already registered has an email and no phone. Do they keep signing in the old way? Are they prompted to add a phone? Is there a migration? This is a product decision that nobody has made yet, and building before it is made means building twice.

Everything that assumed an email. Notifications. The admin panel's search. Any export. Any integration receiving user records. Support tooling. Each of these has a line of code somewhere that assumed the field was populated.

Uniqueness. Two accounts, same phone number, different formats. That is now a duplicate-account bug and it needs a rule.

None of these is hard. There are a dozen of them, each needs testing, and several need a decision from someone who is not in the room.

Why estimates feel dishonest

The client's estimate is based on the description, which is genuinely small. The team's estimate is based on the blast radius, which is not.

Neither party is wrong. They are estimating different things, and they usually do not realise it, so the conversation turns into a negotiation about trust instead of a conversation about scope.

The way out is boring: instead of arguing about the number, walk through what the change touches. Ten minutes of listing usually converts the disagreement into a shared understanding, and quite often into a smaller version of the change that gets most of the value.

What actually reduces the cost

Ask about the blast radius before agreeing to anything. Not "how long", but "what does this touch". The list is the estimate.

Take the reversible decisions early. Whether users sign in with phone or email, whether the product is bilingual, whether there will be more than one user role — these are cheap in week one and expensive in month five. They are architecture decisions dressed as feature decisions.

Write down what is out of scope. A change is only a change relative to something agreed. Without that, every request is a negotiation with no reference point.

Batch changes into a considered round. Five changes assessed together often share work. The same five arriving one at a time over three weeks each trigger their own test-and-release cycle.

The uncomfortable part

Sometimes the honest answer is that the change is not worth it. A two-month cost for a marginal improvement is a bad trade, and the useful thing an engineering team can do is say so plainly rather than absorbing it quietly and missing the deadline.

That conversation is easier to have when the cost is visible. Which is the entire argument for making it visible.