What We Got Wrong About Estimating How Long a Product Takes to Build

Every one of our first few products ran late against our own estimate, and for a long time we blamed the same thing: we hadn't budgeted enough time to write the code. That diagnosis felt right because writing code is the part of building a product that's easiest to picture, so it's also the part that's easiest to estimate confidently and wrongly.

It took a few products to notice the actual pattern. The code was rarely the reason we ran over. The parts we hadn't counted at all were the reason, and they were the same parts every time.

Our early estimates looked something like: two weeks for the core feature, three days for styling, a day for deployment. That's a reasonable estimate for the feature itself, and it was usually close to accurate for exactly that scope. The problem is that a product is not a feature with a login screen bolted on. It's the feature plus everything that has to exist around it before a stranger can use it without asking us a question first.

We were estimating the part of the work we found interesting and skipping the part we hadn't done yet for this particular product, because it's genuinely hard to put a number on a task you haven't scoped. That's not laziness, it's just where estimation naturally breaks down: you can size what you can picture, and in the early days we could only picture the feature.

Account handling was the first one to bite us. "Add authentication" sounds like one line item until you're building password reset, session handling, and the edge case where someone signs up twice with slightly different capitalization in their email. None of that is hard, individually, but none of it was in the original estimate either, and it all has to exist before the product can go live.

Payment and billing logic cost us the same way on Sorted Nexus and Quiz Bru. The subscription flow itself is a day of integration work against a provider's API. Handling a failed card, a downgrade mid-cycle, or what a user sees when their trial ends without adding a card is a different kind of work entirely, and it's the kind that only reveals itself once you sit down and actually list every state a subscription can be in.

The last one was the most consistent across every product: the gap between "it works" and "it works when someone we've never met tries it for the first time with no instructions." Empty states, error messages that make sense to someone who didn't write the code, and the handful of validation checks that stop a bad input from silently breaking something downstream all fall into this category. It's not a feature. It's the layer that makes a feature usable by a stranger instead of just demoable to us.

The honest answer is that these categories don't show up on a feature list, because a feature list describes what the product does, not what it takes to let someone safely and confidently use it. When we scoped a build by listing features, we were scoping the ten percent of the work that was visible and skipping the ninety percent that only becomes visible once you're actually trying to ship.

There's also a risk-aversion angle to it that we didn't recognize in ourselves until later. We tend to want a build plan we can commit to with confidence, and a plan built entirely from named features feels more certain than one that includes a line item like "handle whatever account edge cases turn up." We were choosing the estimate that felt safer to say out loud, not the one that was more likely to be right.

We now build every estimate with a fixed second half that isn't tied to the specific product: account and access handling, payment and subscription states if the product charges for anything, and a pass dedicated purely to error states and empty states before we call something ready. That list barely changes from product to product, which is exactly why it kept getting left out. It felt too generic to be worth writing down, until we started writing it down anyway.

The feature itself, the part we used to estimate most carefully, has actually become the easiest part to size accurately, because building six products has taught us roughly how long our own code takes us to write. The parts that still take real judgment to estimate are the ones that don't show up until a product is close to done, which is exactly why they belong in the estimate from day one instead of getting absorbed as unplanned time at the end.

This same blind spot shows up constantly in technical consulting work, usually from a founder or a team lead who is confident in their timeline because they've scoped the feature and nothing else. Part of what we do in a review is walk through the categories that don't make it onto a feature list on their own: what happens to an account that never verifies its email, what a failed payment actually does to access, what a user sees when the thing they searched for doesn't exist.

None of that is a hard conversation to have, but it's an easy one to skip if nobody's specifically looking for it. If you're scoping a build and want a second pass on what's missing from the estimate before it becomes a missed deadline, that's exactly the kind of gap our services page is built to catch early.

Looking back, we weren't bad at estimating how long code takes to write. We were bad at listing what a product actually needs before it's a product instead of a demo. Once we started estimating against that fuller list instead of the feature alone, our timelines got both longer and more accurate, which felt like a downgrade for about a week and then felt like the first honest schedule we'd ever given ourselves.

If you're in the middle of scoping something and the estimate feels too clean, that's usually the sign the account handling, the failure states, or the billing edge cases haven't been counted yet rather than a sign the plan is actually simple. We'd rather find that out on paper before a deadline than find it out live, and if you want a second opinion on where your own estimate might be thin, our contact page is the easiest way to reach us.