Product Software Upgrades: You Don’t Ship a Version. You Take On an Installed Base

The obligations you inherit at launch compound every quarter after, and almost nobody accounts for them.

There is a meeting I have sat in more times than I can count, on both sides of the table.

A customer has asked for a change. The request is reasonable, the clinical need is real, and the work itself is not particularly hard. Somebody starts building the release plan. And then the person who has been quiet the whole time asks the question: if we push that, what happens to the sites running the older version?

The room goes quiet, because everyone already knows the answer. Somebody out there is going to have to rebuild something they already paid for.

That is the moment this problem stops being theoretical. And it is worth being precise about what the problem actually is, because we mislabel it constantly. We call it interoperability. We call it technical debt. We call it legacy architecture. What it really is: you did not ship a version. You took on a new installed base.

What you actually shipped

On launch day you have one product. Three years in, you have roughly as many products as you have customer environments, and you are accountable for all of them.

Each of those environments has its own operating system, its own connections into the hospital’s clinical and laboratory systems, its own integrations that the customer’s IT group may well have built themselves, and its own tolerance for disruption. None of that was in your design review. All of it is now yours.

That is the part that catches teams off guard. Maintaining what is already in the field is not the tail end of product development. After the first release, it is most of product development.

The field moves whether you release or not

Here is what makes this compound rather than simply persist.

The environment around your device keeps changing without consulting you. An operating system reaches end of support and a platform you validated is suddenly one nobody patches. A health system upgrades its clinical information system and an interface that worked last quarter now returns something slightly different. A component buried in your own software stack publishes a vulnerability. You shipped nothing, and your risk profile changed anyway.

Regulators have also closed the last exit. The expectation now is that a connected device is maintained across its life, with a current software bill of materials and a real plan for handling vulnerabilities after launch. Standing still used to be a defensible position. It is not one anymore.

So the installed base gets more expensive every quarter, and none of that expense arrives as a line item anyone approved.

The fork

Which brings you back to that meeting, and to a choice with no comfortable answer.

Serve the customer asking for the change, and you may strand the customers who built their workflows around what already exists. Protect those customers by branching a version for them, and you have permanently doubled what you maintain. Hold everyone still, and you drift out of step with the environment and eventually out of compliance.

Most companies never actually decide this. They resolve it one ticket at a time, and the accumulated result is a portfolio nobody designed and no one can defend.

That is the real failure here, and it is not an engineering failure. It is a business judgment that never got made on purpose.

Version one is where version four gets expensive

The decision that matters happens far earlier than anyone treats it.

How much compatibility is in scope? Which environments do we commit to, which do we explicitly decline, and what do we say to a customer who wants the one we declined? If we support two platforms today, what is our position when a third shows up with a serious account behind it?

Answer those questions at design time and they are strategy. Answer them at ticket time and they are damage control. Same questions, very different bill.

The companies I see handling this well have done three things. They set the compatibility boundary deliberately and wrote it down, so a customer request meets a policy instead of an improvisation. They built a clean layer between device logic and the outside world, so the field can move without forcing a rebuild of the device itself. And they invested in making change cheap to prove, because the reason teams freeze is almost never that the change is hard. It is that demonstrating the change is safe and compliant costs more than the change is worth. That last one deserves its own conversation, and it is the lever underneath everything else here.

The questions worth asking

None of this is exotic. It is the ordinary consequence of selling a product that lives inside someone else’s environment for a decade or more.

So these are the questions I would put to your leadership team. How many distinct field configurations are we supporting right now, and can anyone say the number out loud? What does our next release break, and for whom? And when we said yes to that last customer request, who decided what it would cost us over the next five years?

If those answers are uncomfortable, that is useful information. Most of the teams I talk to struggle to answer the first one.

Why Suntra

Sustaining a released portfolio is where a great deal of our work happens, at the architectural level, inside FDA Class II and III environments.

• Mapping what is actually in the field: configurations, versions, interfaces, and where the exposure really sits
• Setting a compatibility boundary your engineering team can hold and your commercial team can sell against
• Interface architecture that lets the outside world change without forcing a rebuild of the device
• Modernization that runs alongside active programs instead of pausing them
• Embedded teams that plug into your quality system and stay until the work is done right

Let’s talk about what is in your field and what it is costing you. Visit SuntraMedTech.com/contact.