Your web application will inevitably rely on other services. Fortunately, the last several years have seen a windfall of services that can integrate into your application and lighten your workload. From hosting to email to support, there’s no shortage of great tools that can help turn what used to be day- or week-long tasks into minutes or hours.
Your vendors contribute toward your success or your failure, and you should choose them carefully. Imagine if your hosting company were to go out of business or to neglect its customer service at a key moment. Imagine you were to choose an email provider only to spend hours on end dealing with deliverability or spam problems. The wrong help desk could hinder more than help if it were to be down or unreliable. The possibilities are endless, and if you’re not careful about how you select vendors, the wrong one could do some serious damage to your business. So, based on years of experience, here are my tips to help you avoid bum vendors.
Don’t Roll Your Own Tools
The single most important piece of advice I can offer is that you shouldn’t fall into the trap of building tools or infrastructure you don’t need. Don’t be your own worst vendor. No tool or vendor will be 100% perfect, but deciding to build your own because the best you could find had only 90% of what you wanted is dangerous. You’re wasting your time and resources if you build even one tool that could be outsourced. It’s better to suffer the minor inconvenience and adapt to a less-than-perfect tool than to create the distraction of building and managing tools from scratch.
When it comes to vendors, you’re paying not just for their solutions but also their expertise. They’ve accumulated years of knowledge and experience you don’t have, nor have the time to acquire. Your hands will already be full running your application–the last thing you want is to increase your workload and lose your focus by reinventing the wheel.
If you ever find yourself tempted to roll your own tool, you should weigh the costs. At $100 an hour–a generously low rate for these purposes–even one week of your work is worth $4,000. You’d need to be pretty confident that’s worth the cost compared with the $30 a month you’d pay for a solution that could last you at least a couple of years. And you’d need to be confident that your month’s work would be better than what any of your vendors are offering, and that you could upgrade your software at the same rate your vendors do.
I’ll go a step further and suggest that you don’t use self-hosted applications when hosted services are available. While it may seem simple on the surface, maintaining even one–let alone a handful–of self-hosted tools can quickly become an unwelcome distraction. Security updates, availability, and upgrades are all extra work that take you away from focusing on your product. Self-hosted solutions may be worthwhile for your business in the long term, but if you have a small team, they’re one more burden that can weigh you down.
No matter how stable or perfect a vendor may seem, the unfortunate truth is that anything can happen to jeopardize your application and your reputation. If a company were to be sold, the acquiring company might make significant changes that make your life worse. Companies can go out of business or change their priorities or otherwise put you in a bad spot. Even worse, they might not care enough to take care of their customers.
The amount of time you spend choosing a vendor should correlate directly to how difficult it would be for you to switch vendors. For example, changing exception handling tools is borderline trivial; unless you have a deep integration, you’re not going to struggle to switch exception handlers. On the other hand, unless you’ve invested in some incredible DevOps, switching hosting providers will be incredibly difficult. As a result, you don’t need to beat yourself up choosing an exception handler, but you’ll need due diligence before settling on a hosting provider.
When we launched Sifter’s email integration, we relied on SendGrid’s inbound email parsing. At the time, this seemed more reliable than building it ourselves. But we later learned that this feature was merely an afterthought for them, and they were in no hurry to fix any problems with it. Fortunately, their reliability improved over time, but for those first few months, we were essentially beholden to their whims. The first problem we encountered was that a handful of emails were lost with no option to recover them. By itself, the problem wasn’t catastrophic, but their response bordered on indifference after we reported the problem. That’s when it became clear they were not going to be a good partner.
Later, we began having problems decoding some emails. Once again, we were fortunate that this affected a very small percentage of customers, but it turned out this was a known issue that–surprise, surprise–wasn’t a priority for them. They needed to send some additional information with each request so we could properly decode the content–but it took them over a month to implement. We ended up in a situation where we were forced to ride out the problem because the risk and effort to switch were worse than the risk and effort to wait for them to fix the problems. I’ve never despised being so bound to a vendor as with SendGrid. The product was a mess, and support was worse. In all my years, I’ve never encountered a company so openly nonchalant about bugs and defects. Trusting SendGrid cost us countless hours of development, support, debugging, and lost trust with customers. I learned a lot of lessons the hard way there.
What can you do to avoid being stuck with a bum vendor? There are a few things. The main tactics focus on evaluating vendors more thoroughly if you’re going to have to make a significant investment to integrate with them. The secondary tactics involve keeping those vendors at arm’s length so you can easily switch away.
These days, you can learn a lot about a vendor by searching Twitter. You can see how they treat their customers. You can see if they have patterns of poor reliability. And you can see how people view them against their competitors. Spending fifteen minutes searching Twitter can save you hours of pain. Of course, with any vendor, there will always be a few unhappy campers. The key is to look for patterns. Don’t avoid a vendor over one or two complaints, but if you start seeing a significant number of legitimate complaints, consider it a warning.
Test Their Support
You could find yourself in a difficult situation if a vendor were to have poor support. So you should test their support–really test it. Every company claims to provide great support, but few live up to it. And don’t just reach out to their sales team–really test their support. Are they knowledgeable? Fast? Helpful? Thorough? Do they earnestly care about helping you? Many companies appear helpful when they’re trying to sell something to you, but you need to figure out how they’d stand up if you were to sign up–that’s what really matters. In some cases, it may just take a few moderately involved technical questions that you’re confident would be too advanced for their first tier support. Their response can speak volumes.
Check Their Status Page
With any online service, status pages reveal a lot. They show historical data. They show transparency. If a company doesn’t have some sort of status page, that tells you a lot as well. Take a few minutes to look over their history and how they’ve handled situations in the past. No company is perfect, and often you’ll learn more from how they recovered and learned from their mistakes than whether they made any.
Focus on uptime, performance, and accuracy. Sifter offers a publicly viewable history of uptime reports from a third-party service; anyone can visit availability.sifterapp.com and flip through Sifter’s entire availability history for as long as Sifter has been using Pingdom. Similarly, there’s a separate status.sifterapp.com page focused on communication for current status during outages or other performance issues.
Ask for Recommendations
You should use Twitter or Facebook to ask your friends and colleagues about vendors; it’s never been easier to get honest recommendations for services. In some cases, your friends may pass along your questions to their followers, and that can help bring in more responses. Keep in mind that you might run into some selection bias when you ask your friends about this stuff. (Selection bias refers to participants selecting themselves for a survey–rather than being randomly selected–and that can skew your results.) But it’s a good sign if you receive a slew of passionate responses from people who love a product. And remember, there’s a big difference between someone saying they use a product and someone passionately advocating it.
Look for a Team or Company Page
These days, a large team doesn’t always indicate stability. For a funded company, it could mean they’re burning through their cash and may not be profitable. Similarly, while a small team has a lower overhead, there could be some risk there as well. Personally, the only thing that raises flags for me is whenever I come across a product that isn’t open and honest about its team size. It makes me wonder what they have to hide. Many small teams feel the need to cover up their size. I’d be less concerned about the size of the team, and more that they’re less than up-front about who’s behind the product.
Google and Read Up
Anyone can paint a pretty picture of their company on their website. You need to look past the marketing fluff to find out what they’re really like. Often, the truth is out there in blog posts and online reviews. Take a moment to Google the company, the founders, and any other relevant content. Searching for “[company name] reviews” can unearth a lot of interesting and unfiltered content. Remember, a single bad review could simply represent one person with an ax to grind, but a pattern of negative reviews tends to be an accurate reflection of the business.
Dig a little deeper to understand the company. How old is it? How experienced is their team? Do you trust them? Do they look like they’ll still be in business a year from now? These aren’t easy questions to answer, but if you’re selecting a critical vendor for your system, finding answers for as many of them as you can is important.
Check Blogs and Social Media for Recency
I’ve been collecting a list of interesting services over the years, and when revisiting those services, it isn’t uncommon to come across companies that had shuttered their doors. Although it isn’t foolproof, I’ve found that checking a company’s Twitter account can speak volumes. And if a company has a Twitter account and blog but hasn’t posted an update in months, that should be a warning–who’s to say whether they’re seriously supporting their products or even still in business?
Read the Documentation
One of my favorite signals to understand the quality of a company is to review the documentation. Is it easy to find? Easy to read? Easy to search? Well written? Quality documentation can save you hours or even days. If you’re stuck troubleshooting a problem that’s poorly documented, you’ll be in a tough spot. Even half an hour browsing documentation before committing can help you avoid the catastrophe of trusting a lower-quality vendor.
Do More Than a Superficial Test Drive
The more important a vendor is to your application, the more strongly I’d suggest you try their service before you make a decision. And don’t just poke around or create a trial to see if it’s pretty–use it. Read documentation. Write some code against it. It’ll take you a little longer, but spending a couple of hours playing with an application’s interface or a vendor’s API can help you make the right decision.
Make Sure You Have Access to Your Data
This may seem like a no-brainer, but it’s easy to overlook: does the company give you full access to your data so you could take it with you if you were to leave? Whether the vendor hands over your data through a simple download link or through deep API access, do they treat your data as if it belongs to you and not to them? If a company doesn’t provide a way to export your data–assuming that such a thing would be feasible–that should set off some alarms.
Avoid tightly coupling your application with your vendors’ code, and always keep an eye on your runner-up vendors so you can switch if you find out your first choice isn’t living up to expectations. The catch is that you don’t want to overengineer your codebase solely for the sake of being able to switch vendors quickly–but don’t put yourself in a situation where it would take you more than a day to switch vendors. Just keep in mind that some vendors won’t always be as reliable or as responsive as you’d like them to be.
Treat Your Vendors as Partners
it’s easy to fall into the trap of seeing your vendors as interchangeable parts. It’s best, however, to build a meaningful relationship with them so you know you can trust them. The vendors I appreciate most are those whose staff I know by first name. And I know that if there ever were to be a serious problem, I can contact them and they’ll take care of us. I’ve been lucky enough to have vendors who I look forward to meeting when I’m passing through their town.
This may seem like a lot of time to invest in a decision, but if you avoid even one bad apple, your time will be paid back in spades.