Predicting costs

Most purchases have a very predictable cost.

Whether you're buying an apple at the local grocer or a skyscraper in downtown Manhattan, you can expect to have a clear idea of the purchase price before you agree to the transaction.

This obviously offers some huge advantages over the alternative. Imagine committing to buying a new home for your family based only on an estimated final sales price: We estimate the cost of this home at $500,000, but that's only an estimate, and we won't know the real price until several months after you've signed the closing documents.

Yes, there are business arrangements that work like this. And a highly educated buyer might be willing to take on the risk. But it’s a substantial risk.

I'm not a real estate investor, so I can't tell you lots of stories from that angle.

But I can tell you that in the world of software-related business services, going far over the estimate is very, very common.

If you want an example, take a look at this blog post from a buyer who committed to a project on an estimate of $7,000, and ended up with a cost of $46,000, and a bunch of regrets.

Believe me, I understand how uncertainty and pricing competition puts pressure on providers to avoid fixed-fee pricing. Really unpacking this topic is more than I can do in a short email.

But here's the thing:

By offering only an estimate of cost, and anchoring the final price the number of hours they may spend on a project (and BTW, the “hour” is an incredibly arbitrary metric), the provider is simply shifting that risk onto you.

A price is a price. An estimate, sadly, is not.

All the best,
A.