A Vertical Stack Sounds Great Until You Need to Swap One Piece
Why the all-in-one healthcare suite is sold as convenience and priced as dependency, and what to do about it.
The all-in-one healthcare stack is the easiest yes in the building. One vendor, one integration, one contract, one number to call when something breaks. Every procurement team and every engineering lead has felt the pull, because on the day you sign, the bundle genuinely is simpler. The problem is that the bundle quietly assumes your needs will never change. They always do. And the day you want to swap, upgrade, or add one piece, you find out the thing you bought for convenience was actually priced as dependency.
I want to make the case for the opposite approach. Not because bundles are evil, but because the math on them is asymmetric in a way most teams do not price in until it is too late.
The pitch everyone says yes to
Let me steelman the bundle first, because the appeal is real.
If you run a health system, outsourcing an entire function to one vendor means less to staff, one accountable partner, and a single integration to maintain instead of a dozen. If you build a platform, buying a bundled module is faster and cheaper than building it yourself, and it lets you ship a capability you could not have shipped alone. Procurement is simpler. Security review is simpler. The demo is clean. Nobody ever got fired for choosing the suite that does everything.
These are rational reasons. Anyone who tells you the bundle is a dumb choice has not run an understaffed operation or shipped under a deadline. The bundle solves a real problem on day one.
The assumption hiding in the contract
Here is what the bundle assumes: that the org you are today is the org you will be for the life of the contract.
You will not be. Your payer mix shifts. You add a service line. You go through an acquisition or get acquired. A capability that did not exist when you signed, like same-day funding on submitted claims, becomes available and your competitors start using it. Or you decide that a function you once happily outsourced is now core enough to bring in-house. Every one of those is a normal, healthy thing for a growing organization to do. The bundle was built for the company you were, not the one you are becoming.
Static pricing for a non-static business is the whole trap, and it is invisible at signing.
What “swapping one piece” actually costs
This is the part that gets underestimated. In a bundle, the cost of changing one component is buried in three places: the contract, the integration, and your data.
The contract ties the pieces together, so you cannot renegotiate one without reopening all of them. The integration was built once, by them, on their terms, so unwinding it is a project you did not budget for. And your data lives in their formats, which is the quiet killer. As researchers put it plainly, vendor lock-in is the situation where moving to a different vendor is not possible without substantial cost, legal constraint, or technical incompatibility. In healthcare that is sharper than in most industries, because the data is regulated, the formats are proprietary, and a migration that loses or corrupts records is not an inconvenience, it is a compliance and patient-safety event.
For a platform, the consequence is even more direct: if you do not own the layer that matters, you cannot differentiate on it. You have rented your own roadmap.
Convenience now, dependency later
The lock-in is not an accident. It is the business model. The discount you get for buying everything together is not really a discount, it is a fee you pay later in lost optionality, and you do not feel it until the day you want out.
The clearest illustration the industry has is the Change Healthcare outage in early 2024. One vendor sat underneath an enormous share of the country’s healthcare transactions, processing close to 44% of all funds and roughly 14 billion transactions a year. When that single vendor went down, the dependency stopped being abstract. Hospitals stopped receiving payments. Providers could not verify whether patients had coverage. Pharmacies could not process prescriptions. A problem at one company became a problem for the entire system, because so much of the system had been routed through one place.
You do not have to imagine a cyberattack to feel the same dynamic at smaller scale. Any time a single vendor sits between you and your money, their roadmap, their outage, their price increase, and their priorities become yours. Concentration is convenient right up until it is the thing putting you at risk.
The composable alternative
The alternative is not “build everything yourself.” It is composability: modular layers that interoperate by design, where you own your data, keep your workflow, and can add or replace any single component without touching the rest.
Optionality becomes a first principle instead of an afterthought. For a builder, that means you own your roadmap and you can differentiate on the layer that matters to you while buying the layers that do not. For a buyer, it means you keep your leverage, because the day a component stops earning its place, you can replace it without a forklift. The stack becomes a set of interchangeable parts rather than a monolith you are married to.
This is the real argument for treating financial functions in healthcare as infrastructure: layers that plug in and out, not a single suite that owns the whole flow.
Where this bites in healthcare finance
Revenue cycle, clearinghouse, funding, and analytics increasingly get sold as one bundle. That is exactly the wrong shape for the problem, because the cost of slow reimbursement is the kind of thing you should be able to fix by adding a layer, not by re-platforming your entire operation.
That is the bet we made when we built Thrivory. It is a layer, not a suite. It adds same-day funding of 80% of expected claim value, it sits alongside the systems you already run, and it requires no change to how your team bills. Nothing to rip out, nothing to marry into. If it ever stops earning its place, you can remove it as cleanly as you added it. That is the point. Infrastructure should earn its keep every quarter, not hold you hostage to the decision you made years ago.
A checklist before you sign or build
Whether you are buying a bundle or building on one, ask these before you commit:
What does it cost to leave, in dollars, in time, and in engineering work?
Do I own my data, and can I export it cleanly and completely?
Can I swap or add one component without renegotiating or re-integrating everything else?
Can I adopt a new capability without this vendor’s permission or roadmap?
If you are a platform: does this let me differentiate, or does it quietly commoditize me?
If you do not like the answers, you are not buying convenience. You are buying dependency, and the bill comes later.