The hidden criterion in your tech stack: how vendors handle change

When brands evaluate a new system for their tech stack, the questions tend to focus on what the system does. Features, performance, pricing, the demo, the case studies. All of it sensible.

There's one criterion that rarely makes the shortlist, and it's the one that determines how much of a problem this system will be in two years' time.

How does the vendor handle change?

Every system in your stack will evolve. APIs get versioned. Platforms get migrated. Features get rolled out. Fields get deprecated. The vendors who handle that well will quietly disappear into the background. The ones who don't will become a recurring source of disruption that nobody flagged at selection time, because nobody asked.

Below is what to look for, and what to ask, before a vendor ends up in your stack.

Vendors that communicate well about change make integrations easy. Vendors that don't make integrations hard. Both effects compound over time.

The good ones publish ahead of releases. They version cleanly. They give partners and integrators meaningful warning before breaking changes, and they support legacy versions for long enough to actually migrate. Working with them feels like a partnership.

The difficult ones push changes without notice. They version unpredictably, or not at all. They run on tight deadlines, with no overlap window between old and new. The first you hear about a change is when something stops working.

Both kinds of vendor exist in every category: ecommerce platforms, ERPs, WMS, returns platforms, payment providers. The functional capabilities might look similar. The release discipline rarely does.

A few things signal a vendor that's going to be easy to integrate with over time.

A developer changelog you can actually find. If a vendor maintains one, publishes ahead of releases, and keeps it well-organised, that tells you they take communicating changes seriously. If it takes some hunting to track down, or it only gets updated after the fact, that tells you the opposite.

Some form of versioning. Most major platforms now have a structured release pattern. Shopify is the cleanest example: four major releases a year, date-based versioning, a 12-month support cycle for each version. You always know what's coming and you've got a year to handle it. Vendors without any kind of version structure are harder to plan around because you can't anticipate when change is coming.

Advance notice of breaking changes. The best vendors give meaningful warning, with enough detail to act on. The worst announce things on the day, or after the fact.

Overlap windows during migrations. When a vendor moves to new infrastructure, the difference between a smooth experience and a painful one is whether they support the legacy system and the new system simultaneously while migration happens. That overlap is what makes the work doable, instead of a scramble.

Sandbox access. Can integration partners test against release versions of the system before they hit production? If not, every update is a leap of faith.

Proper partner channels. RSS feeds, dev logs, email lists, dedicated partner programmes. Vendors that invest in keeping their integration ecosystem informed tend to be the ones whose ecosystems work.

None of these things are exotic. The vendors who get it right have all of them. The vendors who don't, don't.

Alongside the obvious functional questions, here are a few worth adding when you're evaluating a third-party system.

• What's your release cadence, and how do you communicate changes to integration partners?

• How long do you support legacy versions of your API after a new version is released?

• When you've done major platform migrations in the past, how did you handle the overlap with existing integrations?

• Do you offer sandbox environments that integration partners can use to test against?

• Where can I find your developer changelog?

If a vendor can answer those clearly, they've thought about it. If they can't, they probably haven't, and that gap will eventually become a problem your team has to deal with.

The reason this matters more than it looks is that release discipline is sticky. Once a vendor is in your stack, you're committed. Switching is painful, expensive, and rarely on anyone's roadmap.

Which means whatever you've signed up to is what you're living with for years. A vendor with strong release discipline will keep being easy to work with. A vendor without it will keep generating the same kinds of problems, on the same kinds of timelines, indefinitely.

The good news is that this is one of the easier things to evaluate. The vendors who do it well are happy to talk about it. They'll show you the changelog. They'll walk you through how they handled their last migration. They'll tell you exactly how long their support windows are, because they're proud of it.

The vendors who don't do it well will struggle to answer those questions clearly, or will give you assurances without specifics. That's the signal.

We work across a lot of vendors, in a lot of categories, and the pattern is consistent: the vendors who treat their release process as part of their product are the ones whose customers stay calm when something changes. The vendors who treat it as an afterthought are the ones whose customers find out about changes the hard way.

When we're brought into conversations about new tools, we tend to push for these questions to be part of the evaluation, not just the functional fit. It's the difference between a vendor that becomes a long-term part of a brand's stack, and one that becomes a recurring source of integration work.

The technology might be a good fit. The way a vendor handles change is what tells you whether the partnership will be.

Want to talk through how we evaluate third parties for the brands we work with? Get in touch.