3 Quick Marks of Vendor Quality
How to tell at a glance if your software vendor is good
Not every software purchase needs a formal RFP, especially when you're trying to move fast on digital transformation. But you still need to be diligent about vendor quality.
Most of these heuristics were gleaned from my years as a Health Tech CIO, but you probably use some version of them already.
You can tell the quality of a company from the outside by understanding the following:
A poor sales experience means a poor company.
Old interfaces mean a lack of attention to technical debt.
Lack of SSO or MFA, regardless of certifications, is bad.
Don't be fooled into thinking these are simple; these are real. Nothing derails a project more quickly than doubts about your vendor selection three months after the project has started.
Commercial Maturity
If a vendor is able to respond quickly and with quality materials, that vendor is more likely to have a mature sales department with competent sales managers. You are looking for maturity of the sales department because it is a leading indicator of maturity in general.
You are interviewing vendors for a regulatory compliance initiative. Both vendors allow you to pick your own meetings. The first vendor misses the initial meeting even though you set it for a week out. The second one makes it to a meeting that you set for the same day, brings an expert sales engineer with her, researches the company in the 3 hours warning you gave her, and responds to your request for documentation that evening.
The difference isn't always this stark. However, you can read the signs for any deal.
A few concrete markers:
Quick response time
Ability to immediately provide high quality product or service materials
Highly skilled sales engineers who can answer questions on the spot
The bottom line is this: if sales feels like they are winging it, so is the rest of the company.
Development Maturity
A straightforward metric is the look and feel of the software. Does your vendor's software look modern, simple, and built for purpose? Or does it look like this:
Twenty-year-old interfaces go with twenty-year-old software architecture and infrastructure. What's a good way to expose yourself to ransomware? Buy something that looks like the above. Security incidents have a way of ending up in board slides.
Another useful heuristic is the reporting system; is it modern, faceted search, or is it a few canned reports that can dump out a CSV?
There may be reasons to go with old, mature software, but these signs should make you start asking questions.
Lastly, if the software looks patched together from multiple acquisitions, that's a marker. Sometimes this is only a temporary condition and can be ok. But if it's been 5 years since the acquisition, this may be due to high complexity or lack of maintenance. Many, many companies are driven by feature requests from large prospects, with underinvestment in technical debt. Even healthy companies should have at least 20% of their dev effort allocated to tech debt reduction, and sometimes more.
This McKinsey report shows useful insights.
Very old software typically reflects a company's capital allocation priorities.
Security Maturity
Just about every company is going to call themselves "SOC2 certified." The problem with this is that it isn't as meaningful as it used to be because the SOC2 market has been flooded with low cost, highly automated vendors. It's an interesting situation, but should you trust a SOC2 report that someone paid $5k for? I'm skeptical.
You should ask your vendor for all of their certifications, but also ask them a few simple questions up front. Like: "Describe your support for SSO and MFA." If a company uses a qualified vendor like Auth0, Okta, WorkOS, or other high-profile, up-to-date identity management companies, that is a good marker.
One has to wonder these days, why companies don't feel that they must support the latest standards like passwordless authentication. NIST SP 800-63 has been talking about this for years now, and the Internet, so to speak, is a dark alley on a cloudy night.
Among the worst offenses: home-grown authentication or authorization. That's bad. Thankfully, I see that very rarely these days.
These markers are certainly not meant to replace a diligent evaluation. Note that I didn't mention anything about financial health markers or integration complexity.
You know your own projects, but you can certainly improve your odds of success by watching for the tells.