When someone asks how long a software project will take, you can estimate the work you know about. But what if the work you haven't found is the hardest part? At a FinTech startup where I was CTO, we cut scope and the CEO added padding to my estimate, yet the project still took about four times as long. The funds we had raised were running out, and the company nearly shut its doors before the product was done. So what could we have given the business instead of a date that looked safer than it was?

Software estimates miss for the same reason mine did: we size the part we don't know like the part we do, and the part we don't know is where the date goes. Mine is one story, but the same thing happens on teams that do everything right, and padding, the fix most of us reach for, doesn't save you.

Difficulty Wrapped in Difficulty

The startup needed a subledger, a data model that lined up every transaction from crypto exchanges, banks, and brokerage accounts, so a user and their spouse could see their pre-tax, taxable, and Roth accounts in one place. Some transactions even had to be split.

I didn't want to give an estimate, but the business had to know whether this was worth doing or whether it would sink the company, so I gave one. I was confident we could build it. But I had assumed the parts I didn't know yet were about as hard as the parts I did.

They weren't. Some partners' APIs weren't finished, and we were only their second client. Every partner needed its own integration. One partner sent data to our webhook and wouldn't send it again if we missed it. So that webhook could never go down, and we had to save the raw data the moment it came in and put it in a queue, so we could process it and retry on our side. Each unknown opened onto a harder one. It was difficulty wrapped in difficulty.

That was one project, though, and you could say I just missed something. The next reason shows up even when nobody misses anything.

You Can Only Estimate What You've Done Before

A good estimate comes from having done the work before. But in software, when your team has built something before, it doesn't build that thing again. It reuses what it has. So the work left to estimate is mostly work nobody on the team has done, and that is the work you can't size.

Now, with AI writing a good share of the code, the part you've done before shrinks even more, because the typing goes fast. That sounds like good news for the date, but it means more of every estimate sits in the part nobody has found yet.

So most teams, and most CEOs, reach for the same fix. It's the one that fooled us.

Padding Doesn't Fix a Number That's Missing Work

Our CEO padded my estimate, and we cut the number of integrations, which should have been plenty of room. It still took about four times as long. By then the money we had raised was running low, so the CEO had to raise more, which diluted the earlier investors, and most of the team was let go while that happened. We got the product done, but the company almost shut its doors first.

Padding helps when you're off by a little on work you understand. But when you sized the unknown part wrong, you're adding a cushion to a number that's missing most of the work, and the padded date looks safer than it is, so everyone plans around it.

Two Numbers, Not One

All that to simply say this: stop giving one date for work that has two kinds of parts in it.

Give a date for the part your team has done before, because you can stand behind that number.

For the part nobody has done, don't guess at the work. Give a date to come back with what you found. Name the one unknown that could change the plan the most, like whether a partner's API actually works, and agree on how much time and money you'll spend checking it. Then come back with what you learned and what you still don't know. At that point the business can keep going, cut scope, or stop before it spends the rest of the money.

You can't estimate work you haven't found. You can estimate how long you'll spend finding out.

If you lead the team, ask for both numbers. The second one tells you early whether the work is worth the money, which is what the business needed from me and never got from one padded date.

Where This Fits in Intelligent Engineering

Intelligent Engineering is the operating model for engineering organizations in the AI era. It is what comes after vibe coding.

The date you can stand behind covers more of a project when the work your team has already solved is written down once, and every developer and every AI session starts from it. Intelligent Engineering works that way, so less of each new project lands in the part nobody has done before, and your dates get closer to something your team can trust, support, and scale.

Chad Carter is the creator of DevNitro, the Intelligent Engineering platform. He's spent 29 years building software, served as CTO at multiple companies, and was a Microsoft MVP from 2009-2019.