> ## Content Index
> Fetch the complete content index at: https://marginsofcare.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Collaboration And Compatibility, The Case For Buying Professional Software
- URL: https://marginsofcare.com/collaboration-and-compatibility-the-case-for-buying-professional-software/
- Published: 2026-11-10T20:12:30.000Z
- Updated: 2026-11-10T20:12:30.000Z
- Author: Eva Worst

Last week in [Down The Cost Ladder, The End of The Health Tech Market?](https://marginsofcare.com/down-the-cost-ladder-the-end-of-the-health-tech-market/) I pointed out that LLMs enabled anyone to build the perfect product for their needs and then raised two questions:

> Today, thanks to technology, anyone can build any software for the cost of a dinner for two. What’s even more critical, because of that, those software products can be personalised on the individual level, unlocking a type of product-market fit that was not possible before.

> This raises two really important questions:

> 1\. In a world of software abundance, what will be a durable competitive advantage for health tech companies?

> 2\. In a world where anyone can build exactly the software that they need, essentially for free, why would they buy anybody else’s software?

> My answer to the first question was that it will come down to humans and trust, to conformity and adoption. And my answer to the second was leaning towards: there is increasingly no need for that.

Those were only half right, however, as there is one important consideration that I hadn’t taken into account, which is that many clinical workflows require collaboration and that in turn requires compatibility and interoperability.

To be clear, there are plenty of cases where a workflow starts and ends within the same institution, maybe even within the same department, such as the ER. In those cases, whether the staff uses off-the-shelf software or a vibe-coded one-of-a-kind app provided by the IT department makes no difference, as long as the software works and as long as everyone has access to to the same version.

That last point becomes problematic in the cases where collaboration between different hospitals and systems is required. If hospital A and hospital B have their own unique software, that produces its own unique data structures, then you can’t just export and import a file from one system to the other, without manually harmonising it. 

This problem has always existed and is one of the reasons there are so many initiatives that push for standardisation and having one source of truth, which is the goal of the [electronic health record](https://marginsofcare.com/epa-data-flow/). But by unlocking the capability of hospitals to build their own unique tech stack, AI brings this to the next level. Not only will there be increasingly more apps, even if most may only serve a single customer; but also the incentives to build and maintain an interoperable software will decrease.

Creating great, useful products is not easy and while AI makes the product creation part easy, it doesn’t necessarily make the great part easy. SVPG [has an excellent article](https://www.svpg.com/ai-and-the-future-of-the-product-role/) on how software product development changes because of AI and the key take away is that problem discovery and product discovery are becoming increasingly critical for building software.

And as many tech companies struggle to successfully implement those best-practices, although it’s their sole focus, I do wonder where that leaves regular IT departments and other AI-enabled intrapreneurs, whose product development experience is likely considerably more limited.

This is good news for [health tech companies](https://marginsofcare.com/heidi-cuts-jobs-going-against-incumbents-trust-as-a-moat/), as it seems like the healthcare marker will still need professionally developed software products.