We don't estimate scope: we cut scope to fit the date

Every founder has heard “how long will it take?” answered with a number. And nearly every founder has watched that number double. It isn't dishonesty. The number was just calculated the wrong way.

On January 24, 2026, software engineer Sean Goedecke published a piece that sums up what I've practiced for years. The first line of his thesis is blunt: “It's not possible to accurately estimate software work.” In How I estimate work, he explains why and what he does instead.

Why estimating scope doesn't work

Goedecke's argument is simple. Most software work is unknown until someone starts doing it. You don't know how long an integration with a system you've never opened will take, or what a flow nobody has tested with a real user will cost. Known work is easy to estimate. The unknown dominates the total.

He also notes that, inside companies, the estimate rarely starts with the engineer. Whoever asks already has a date in mind. The estimate becomes a negotiation.

What to do instead: start from the date

Instead of asking “how long will this project take?”, Goedecke asks “which approaches fit this timeline?”. In his words, the job is to find “the set of software approaches that match that estimate.”

His process has four steps:

1. Understand the context before the code. How much pressure there is, how essential the project is, what timeline is expected.
2. Go into the code with the date in hand. And ask what's possible within it.
3. Look at the unknowns. How many unknown areas each approach forces you to touch, and how risky each one is.
4. Present options, not a number. Each path with its risk and trade-off. The decision-maker chooses.

If no approach fits, he says, maybe it's the requirement that needs to change.

How this became the Studio's method

For a founder, Goedecke's reasoning translates directly. You have a date that matters: a funding round, a trade show, a season, the end of your runway. The product has to be live by then. So the right question isn't “how long will my whole product take?”. It's “what's the best product that fits by then?”.

We don't estimate scope. We cut scope to fit the date. In practice:

• The date comes first. It's written into the contract.
• Discovery maps the unknowns. Integrations, legacy data, business rules nobody documented. That's where the risk lives.
• Scope is designed for the date. Every feature goes in or out for a reason. What's out goes on a written list for the next version.
• The price is fixed after discovery. You can only fix a price once scope and date are locked together.

Case 1: AI Vou Eu, live in 4 weeks

AI Vou Eu is an AI travel SaaS.

With the date set, the work was choosing the core flow that had to work at launch and getting everything else out of the way. The product went live in 4 weeks.

Case 2: LCX, one system in 29 days

LCX is a travel company operating in more than 10 countries in South America. It had one system per country. The ask was to merge everything into a single system.

A project like this, estimated the traditional way, would turn into a months-long schedule, with each country asking for its own exceptions. Starting from the date, the question became “what has to be common to every country on day one?”. The single system went live in 29 days.

What this method asks of you

Cutting scope to fit the date isn't magic. It asks three things of the founder:

1. A real date. Not “as soon as possible.” A date with a reason.
2. Willingness to say no. To good features that aren't essential right now.
3. Trust in the next version. What's cut from launch doesn't die. It comes back with real usage data to decide whether it's worth it.

In return, you get something no estimate gives you: a product live on the date it matters.

What this means for you

Next time someone answers “how long will it take?” with a number, ask back: “what would you cut if you had to deliver in half the time?”. If the answer is “nothing”, that number is a guess. If you get a clear list of options and risks, you're talking to someone who understands where delays come from.

And if you have a date and a product that needs to be live by then, our custom system and SaaS development service starts with exactly that conversation.