Clients always want to know how long something will take. This is as certain as death and taxes. And in our field — software development — that number is almost always unknowable. Our friend Adam Wathan used to say at Tighten: "We'll never know less about this project than we know right now."
Why estimates are fake
First, software is finicky and unpredictable. Complexity is very good at hiding. The ten-minute task turns into a three-day investigation because of some assumption that turned out to be wrong, or a library that behaves differently under load, or a subtle bug in code nobody's looked at in years. This is the nature of the work.
Second, we almost never know the actual definition of done. A client will say, "we want to add a CRM to our backend. How long will that take?" Well, that depends entirely on how feature-rich the CRM is. We can picture a version that takes an afternoon, and a version that takes months. Coaxing out all the assumptions, pinning down the scope, shaping that raw request into an actual project — that is itself real work. Scoping a serious project properly takes time and expertise, and we want to get paid for that work.
Third, we don't know what the prior art looks like in their product. As an agency, we're usually stepping into someone else's codebase. Sometimes that means spending time upfront just getting things into a workable state, so that our improvements compound instead of piling onto their tech debt. Even understanding what's already there means reading code and rolling up our sleeves. Again: this is work.
Producing a real estimate is a project of its own
A reasonable estimate requires deep product work and deep code review work. It's not a vibe someone pulls out of the air — it's days or weeks of investigation. And at the end of it, you still have an estimate, not a feature. Wouldn't you rather we just start on the real work, instead of spinning our wheels on things that are genuinely inestimable?
Plenty of agencies will hand over an estimate anyway, because the client insists on one. We refuse. Too often, the client takes that number, strips it of every caveat we attached to it, and delivers it to their boss as a promise. Now we're set up to fail before we've written a line of code.
Start small instead
Our way around this is to just get started with a low commitment. The first few weeks of work are low risk for the client, and they start getting real feature development immediately. How much better is that than spending weeks producing a sixty-page RFP that is essentially a work of fiction?