The cheapest and most expensive

I recently discovered David Cain’s Rapititude, and #4 of his 88 truths article really stuck with me: ” 4. The cheapest and most expensive models are usually both bad deals. “

It’s obvious once you put it that way, but in practice, we still get stung by buying the cheap option only to have it fall apart immediately. Or we’re wracked by the buyer’s remorse of the too expensive option, recognizing it was overkill for our needs.

You see this in B2B software transactions too, though because it’s company money rather than my own, we tend to act a bit more removed from the emotion. But in software, “cheap” tends to be less about tangible quality, and instead about the tradeoff you make between price and annoying downsides.

Poor uptime.

Slow support.

Missing functionality.

That last one is particularly troublesome for me, but its inverse, unnecessary functionality, is often the biggest issue with the more expensive option. I used to justify the more premium choice based on the idea that we’d have the functionality if we ever needed it, and later regretting the choice as we never reached that idealized state.

The best way I’ve found to dodge the overkill solutions is to look only at functionality I need today. or at least, in the next 12 months of any contract I sign. Not some aspirational, imagined future where I have the human resources and time to actually leverage excess functionality.

And the best way I avoid the too-cheap solutions is asking what if questions, and talking to my network. If something seems like too good of a deal, it usually is.