And What I Learned About Estimating Software Projects

If you’ve ever cheerfully said, “It’ll take a week, tops,” only to find yourself still pushing commits on day 26, I’ve got a story for you. This was meant to be a simple build — and turned into a crash course in why we developers are terrible at time estimation (but can get better).

The Problem: A “Quick” Build That Wasn’t

The task seemed harmless: a small internal web tool, clean UI, a couple of APIs. I confidently told my team it would be wrapped in 5 working days.

Reader, we were lucky to finish before a whole month passed.

The trouble started early. Requirements shifted slightly (twice). A “simple” SDK turned out to be aggressively undocumented. And worst of all, the scope kept growing — new “must-have” features appeared mid-week like surprise bosses in a game level I thought I’d already beaten. I joked to a friend that this was becoming an “app development cost UK horror story“ — where the biggest bill is your own optimism.

The Reality Check: Actual Studies Say We All Suck at This

Right around week three, I hit a low point and decided to look into just how common this was. That’s when I found a paper by Jørgensen & Moløkken (2003) — a review of more than 20 surveys on software project estimation.

Their conclusion? Only 10–30% of software projects actually land on time. Most of them overshoot by 30–50%, and many go way beyond that. Suddenly, I didn’t feel so alone.

The Fix: Start Tracking Yourself

Instead of beating myself up, I started tracking my estimates vs. actuals. Every task. Every feature.

What I found? I consistently underestimated by about 35%. Which, shockingly, matches the studies almost exactly.

So now, I add a buffer — and more importantly, I write down risks next to each estimate. If something’s vague, I flag it. If it depends on another team, it gets extra padding. These notes help me remember why I thought it would take 2 days — and why it didn’t.

Lessons That Actually Help

• Track everything: Estimate, actual time, risk level.
• Build a say/do ratio: How much you planned vs. how much got done.
• Add explicit risk buffers — even if it feels like overkill.
• Give ranges (“2–4 days”) instead of single-point guesses.
• Look back after every project: Where did you go wrong? Where were you spot-on?

Final Thoughts

So next time you’re estimating the cost of developing an app UK clients dream about, remember: precision is nice, but honest uncertainty is better. Tracking your estimates helps turn painful lessons into future wins — and makes those last-minute saves feel a little less like miracles.

Want the spreadsheet I now use to track this stuff? Just drop me a message — I’m happy to share!