25.01.2025
A comment on estimates
Software estimates are notoriously difficult to get right. Everyone knows that a weakly defined scope is a huge risk in itself, but getting out the old chisel and making every requirement crystal clear will take almost the same time as just developing the solution itself, so where's the sweet spot?
I've visited this topic a great number of times, on old blogs, in talks, in presentations, I've even been hired solely for the purposing of helping teams make more accurate estimates, but by and large it remains a difficult problem. I was reminded of this after reading this post on LinkedIn:

You can read the entire post here, which I recommend you do because it's a great story, but in short: This guy (Marius) had coded for 22 hours straight. 5 minutes before their demo a 3rd party dependency suffers an outage and after a grueling 22 hours he pulls off an 8 minute recovery and the demo is a success!
How you estimate a process that ends 3 minutes after the planned presentation is interesting and requires some trade offs between time spent planning and time spent implementing but I was intrigued to read this take:

Initially you'll be quite impressed by this comment. Peter, a full time AI-Alchemist and Game Developer instantly cuts the job down from 22 to 2 hours - 2½ ordinary business days, a whopping 90%! That's quite a reduction. How's that possible for the same job?
You might not be convinced that Peter could actually pull it off, but that's actually just a matter of scope. I think that Peter could pull something resembling a newsletter agent off in 2 hours. And I believe that Marius, the guy pictured above, would produce roughly the same in those 2 hours.
So what's going on over the next 20 hours? That's where things get interesting.
I guarantee you, that Marius did not just eat bananas and listen to music for 20 hours. Let's use a general case to explain: You're asked to build a tool which scrapes Hacker News every day at 14:00, takes the 3 most trending stories and generates a summary.
After 2 hours: The base engine is done. We have a system unit/job which repeats every day at 14:00 and does exactly what it's asked under ideal circumstance.
Some developers stop here. Their estimate is 2 hours.
After 4 hours: The app can survive a power outage at 14:00 and will resume as soon as it's possible.
After 5 hours: The app can survive multiple days without power and provide a neat report of what was missed.
Many developers stop here. They seem twice as slow as their counterpart above.
After 12 hours: The app can deal with tie-breakers, new promoted stories without actual votes, can detect bot/ai generated content, can proxy around scaping detectors.
After 18 hours: Everything is customizable. Which kind of articles? How many pictures do you prefer? How long? Any authors that deserve special attention? Any domains we never want to scrape? Any time-constraints, load-constraints, multi-threaded massively parallel, deploy anywhere considerations?
After 22 hours: A hot-swappable backend where even in the case of complete outage over at Hacker News, we can swap parts around in 8 minutes or so and the show goes on.
Which model works?
The customer decides of course. But with experience comes the ability to present and help weigh all of these trade-offs. The 22 hour model is 11x more expensive but it may very well be just what you need. And perhaps the 2 hours model would absolutely ruin your business, perhaps not. Picking trusted experienced partners is the first key, crystal clear, honest and transparent communication is the second.
Usually, if you receive 2 estimates for the same job which vary wildly, you shouldn't assume that the lowest offer is from the best/fastest team, instead consider the following
- Which part(s) of the scope are open to interpretation?
- Are all teams considering the right tools for the job?
- Are all of our acceptance criteria understood?
I remember back in 2008 when I was just starting out as a solo consultant, I was asked to provide an estimate for building an e-learning platform. The brief had a lot specifics about the learning experience, how data would be loaded, graded etc, but it actually left out an important details: Which platform to deploy on?
Some of the language suggested an online experience, other parts were neutral. I asked the customer directly and it turned out that they wanted 1 version to run in the browser and another as a native, fully offline, desktop application for Windows and Mac OSX - And this was all 1 project. Can you imagine the range on the estimates they received? I imagine anything from 20 hours to 500 hours depending only on how well you understood their brief.
In conclusion
The perfect estimate is the one which
"Perfectly meets the clients expectations and completes after the exact amount of work specified and which carries an acceptable cost"
If you have experienced people on board, using the right tools, who clearly understand what's expected then for the lowest bids, consider if they are leaving anything out. For the highest bids, consider if they are 'gold plating' - For all of them, remember that estimates are just that. Estimates. We are trying to be very specific about something which is usually too complex to sum up in a single number.
Specifically for Marius - I loved the story. I think the 22 hours were well spent and the proof is in the successful demo, well done! However, if you'd like to skip one of the mistakes that I made early in my career, I offer this advice: Using a larger monitor at a comfortable distance with it's center directly in front of your eyes will make your work-life comfortable and enjoyable well into your 40s. You might feel like this takes you out of the bubble and slows you down, but after a while, I think you'll find that the opposite is true.
Having your head tilted downwards, especially with headphones on, can lead to career ending headaches and miserable days at the office. You might think I'm exaggerating but trust me on the sunscreen (that's a Baz Luhrmann reference for you young people).
(disclaimer: I am in no way affiliated with the guys over at Alvas.ai, but I am impressed by the work they're doing and my hat is off to them)

Lau B. Jensen
Lau is a seasoned Danish software developer and consultant with over 15 years of experience in backend systems, web development, and functional programming using Lisp and Clojure. Since 2007, he has co-founded and scaled multiple successful startups while navigating the venture capital landscape. Lau combines deep technical expertise with entrepreneurial insight, delivering robust, scalable solutions tailored to business needs. Creative, driven, and results-/quality oriented, he thrives turning bold ideas into reality.