Builder’s Fallacy

March 2025

Technical founders frequently drastically underestimate the time it takes to ship a product, and have it adopted by customers. A famous example is:

The root of this fallacy is that when an engineer estimates the amount of time it takes to ship a product, they are estimating:

How long would it take to build this, assuming nothing goes majorly wrong, and with a bit of extra time for padding.

There are two problems with this estimation:

  1. In large, complex technical project, many things go majorly wrong and these issues account for ~80% of all the time spent writing code.
  2. Building the initial product (as in writing the code) is only 5% of the work. 95% of the work is:
    1. Getting customers to adopt the product
    2. Figuring out how to measure the success of the product
    3. Responding to customer feedback
    4. Doing customer research to figure out how to make the product better
    5. Customer support, writing docs, creating tutorial videos
    6. Building internal tooling so you can effectively support customers
    7. …and a lot more.

There are two dangers that come from this fallacy:

  1. Starting projects that just aren’t worth it: If a project looks like it will deliver 2x ROI, but you’re suffering from builder’s fallacy and only estimate the initial optimistic costs to build, in reality the project will deliver 0.1x ROI.
  2. Abandoning projects before you realize value: If start a project assuming it will take 2 weeks, and after 6 weeks have finished the building but don’t have customer adoption, shifting focus from the project will lead to 0 realized value, 6 wasted weeks, and dead code. But to take the project to customer value might take 120 weeks, which you don’t have. This is a rough place to be.

To defend against this fallacy, you have a few strategies:

  1. Instead of visualizing the effort to just build the initial version, visualize the effort to also:
    1. Figure out how to sell the product or drive adoption in other ways
    2. Write documentation and supporting materials, and update these with customer feedback
    3. Get in contact with users, and do user research to make the product better
    4. Answer customer questions, and improve the product experience based on questions
    5. Build internal tooling to make it easier to answer customer questions
    6. …and more
  2. Use the rough heuristic as follows, when judging if a project is worth the cost:
    1. If it’s a simple and well understood project, quadruple your initial estimate.
    2. If it’s a complex and net-new project, assume it will take 100% of the implementor’s time going forward, forever.

Related Reading