THE DOUBLE STANDARD PARADOX IN SOFTWARE BUYING

In July 2024, a faulty update from a major cybersecurity vendor caused a widespread outage. Microsoft estimated that approximately 8.5 million Windows devices were affected.

An established name had not prevented failure. A large customer base had not prevented disruption.

None of this means every customer should have abandoned the provider. Buyers have legitimate reasons to consider its capabilities, history and ability to recover.

But that is precisely the point.

When a market leader fails, the discussion can focus on recovery:

What happened?
How quickly can it be fixed?
What will prevent it from happening again?

When a lesser-known vendor fails, a different question can dominate:

Who decided to buy from this company?

The first discussion examines the failure.

The second puts the purchasing decision—and the person behind it—on trial.

That difference matters long before anything goes wrong. It influences which vendors reach the shortlist, which recommendations receive support and which alternatives disappear behind the phrase “too risky.”

The newcomer is competing against more than another product.

It is competing against the protection a familiar name gives the person signing off on the decision.

Enterprise buyers carry real responsibility. A failed implementation can disrupt operations, consume budgets and damage customer relationships.

But the organisation’s exposure and the decision-maker’s exposure are not identical.

Choosing a widely used provider offers a convenient defence:

“Other companies chose them too.”

Choosing a newcomer requires a more personal explanation:

“We examined the alternatives and recommended this company.”

The second statement may reflect a thorough evaluation. It can still be harder to defend after a failure.

A decision that is easier to defend is not automatically a decision that is safer for the business.

Confusing the two rewards familiarity—even when the evidence deserves a closer look.

Financial resilience, support capacity, security, implementation and continuity all deserve scrutiny.

But scrutiny should produce specific findings.

➜ Which requirement remains unproven?
➜ Which failure scenario cannot be managed?
➜ What evidence would resolve the concern?
➜ Has the established alternative been examined against the same criteria?

If these questions cannot be answered, “too risky” may be concealing an unwillingness to recommend the unfamiliar.

And if no evidence could change the verdict, why put the vendor through an evaluation?

A process that invites proof but cannot accept it wastes everyone’s time.

An established relationship can reduce uncertainty. Buyers may know the support team, understand the product’s limitations and have working escalation procedures.

Those are tangible advantages.

They should be weighed alongside tangible disadvantages: difficult exits, limited flexibility, unresolved service problems or dependence on infrastructure the customer cannot influence.

A familiar risk does not disappear because the organisation has learned to live with it.

Nor does an unfamiliar provider become unacceptable simply because evaluating it requires more work.

The relevant comparison is between the risks of both choices - not between one vendor’s weaknesses and the other vendor’s reputation.