The "What Would Hurt to Change" Question

In one line: For any decision, ask: if this is wrong, what would it cost to fix? — then match your deliberation to that cost.

In plain English

This is the practical version of the reversibility test. Don't think abstractly about whether a decision is "important." Imagine concretely that you got it wrong, then estimate the fix. A button vs link mix-up? 30 minutes. A wrong database choice? Six-month migration. That difference should drive how much time you spend up front.

This is a variant of the reversibility test, but practical: imagine you're wrong, then estimate the cost.

Examples

"What's the framework?" Wrong → 6-month rewrite. High cost.

"Should this be a button or a link?" Wrong → 30 minutes to switch. Low cost.

"What's the API contract?" Wrong → break all consumers. High cost.

"What's the database schema for this new feature?" Wrong → migration with possible data loss. Medium-high cost.

"What library should we use for HTTP requests?" Wrong → search-and-replace in a few files. Low cost.

When the cost is high, slow down. When it's low, move fast.

Worked example: applying the question in a planning meeting

The team is in a one-hour planning meeting. Five decisions are on the table:

Decision	"If wrong, fix cost"	Time to spend now
Which auth provider (Clerk vs Auth0)	1-2 weeks of integration	15 min
Database (Postgres confirmed)	3+ month migration	Already decided
Color of the primary CTA	5 min PR	1 min
Public API URL structure (/v1/...)	Break every customer	20 min
Logger library	1-day search-replace	2 min

Total time spent: 38 of 60 minutes — concentrated almost entirely on the public API contract and the auth provider, with everything else moving fast. That's the correct allocation, and it falls out naturally from asking "what would hurt to change?"

Highlight: the trick is being honest about the fix cost

People consistently underestimate the cost of changing schemas, public APIs, and shared infrastructure — and overestimate the cost of changing UI, libraries, and folder structure.

When estimating "what would it cost to fix," include:

• The code change itself.
• All the downstream consumers (callers, customers, other services).
• The migration plan.
• The communication and coordination cost.
• The dropped-on-the-floor improvements during the migration.

That bigger number is the real cost. Use it to set deliberation budget.

Common mistakes

Where people commonly trip up

• Estimating fix cost in engineer-hours but not calendar-time. A migration that's "two engineer-weeks" might span six months once you account for code freeze windows, customer communication, security review, and waiting for the data team. Pain isn't just hours — it's elapsed time during which the team is partially blocked.
• Counting only the engineers and forgetting everyone else who pays. A breaking API change might cost your team 3 days; it might cost 40 customer engineering teams a week each. The right "what would hurt" question includes external pain, not just internal. Public APIs are expensive because everyone else also has to do work.
• Assuming "we can always migrate later" is free. Later you'll have more code, more customers, more integrations, and a team that's lost the original context. The fix cost grows monotonically with time. Estimate the cost at the point you'd actually do the migration, not today.
• Letting low-stakes questions waste high-stakes time. The point is asymmetric attention, not equal attention to every decision. If your team is bikeshedding the logger library in the same meeting where you're deciding the public API contract, stop the meeting and reorder — those two decisions deserve different rooms entirely.

Page checkpoint

Checkpoint Quiz

Did 'what would hurt?' stick?

Required

What's next

→ Continue to The "Why Are You Doing This?" Question — connect every change to a real outcome.