Appetite, Not Estimates

Estimation is waste. Estimates are based on known unknowns, but real problems are unknown unknowns. By the time the estimate is finished, the thing could've already been built.

Why Estimates Fail

Ask "how long to build authentication?" and the answer is a number. What that number won't include: social login breaking behind a corporate proxy, password reset emails getting spam-filtered, 2FA edge cases for international phone formats. None of that was in the estimate. All of it affects the timeline.

This isn't a planning failure. It's the nature of software. The #NoEstimates movement exists for a reason — estimation is difficult, often impossible, and almost always misused as a commitment.

Scope to a Time Box

Instead of asking "how long will this take?", ask "how much time is this worth?" That's appetite-based scoping. The client sets the time box first, then the developer figures out what fits inside it.

Six weeks for this problem. What's the most valuable version that can ship in that window? If everything can't fit in six weeks, good. That means being honest about what's essential versus what's nice-to-have.

How It Works in Practice

Start with one question: "Six weeks — what's the single capability that creates real value?" Build that. Get it in front of users. See what actually happens.

Then, if needed: "Another six weeks. What should be added based on what was learned?" Iterative scoping beats upfront estimation every time, because it's grounded in reality rather than speculation.

When Clients Want a Total

Some clients will ask for a fixed-price total. That's a fair question with an honest answer: "Phase 1 is six weeks at $X/week. After that, both sides will know whether Phase 2 is needed and what it should include. That's more accurate than a year-long estimate that'll be wrong."

Some clients need the false certainty of a fixed price. This approach isn't for them. For clients who value flexibility and honesty over fabricated precision, appetite-based work is the better deal.

What the Developer Is Actually Selling

The developer isn't selling the ability to predict the future. That's a lie, and clients who've been burned know it.

The developer is selling incremental value, real adjustments based on what both sides learn, and honest communication throughout. That's the offer.