Web services are all about trust, and require more of it than most other businesses. I need to trust that a restaurant will serve me food that’s delicious (or at least sanitary), but it doesn’t matter much if they stay in business. In fact, I’ve rushed to eat at restaurants because I know they’re closing.
With packaged software, trust mattered a little since we all want updates. But if the software in the box is good you can use it for years after the company that made it is shut down, as I did with my favorite HTML editor back in the ’90s.
With any web service, you’re out of luck the moment a company stops supporting it. It requires a tremendous amount of trust to use a web service for an important business function. We’ve recently seen a couple examples of services shutting down not because no one used them or they ran out of money, but because larger companies bought them who didn’t value their userbase.
Anyone who’s built things on the web will have their trust betrayed more than a few times from service shutting down on them, yet they still need to trust. Where would Twitter be if they’d built their own server farm early on rather than relied on Amazon for AWS. Would GroupMe have ever even happened had its founders not trusted Twilio. We’re currently implementing Intercom.io as Muck Rack’s primary CRM both for its current features (which are impressive) and for the features they told us are on the way. That takes trust, or at least a leap of faith.
A grizzled entrepreneur once told me “trust is always given when it’s not deserved”. I’m not sure I agree with that, but it’s resonated with me over the years.
Is it possible to evaluate a service not only on its current features and support, but on its future prospects of serving its customers?
Photo credit: Trust by Joi, on Flickr