There's a cognitive trap I often find myself pondering, one I've taken to calling the iceberg fallacy. It is some bastard cousin of the sunk cost fallacy, but inverted in time: instead of overweighting past investment, it underweights future obligation. Sure, software is a business of marginal costs insofar as the replication is free, the distribution is free, and the next user is free. But the marginal cost of the feature is hardly zero if you consider maintenance. Each new user interface, each data construct, and certainly every API is, in a vacuum, a liability the moment it ships.
Look no further than athenahealth's API change log to get a sense of the burden:
They've built one of the most expansive developer-facing APIs in the EHR market, and the change log is a receipt worth examining: a steady drumbeat of corrections, deprecations, field additions, bug fixes, version bumps, and clarifications. It is decidedly non-sexy (I will debate anyone that there are absolutely sexy API drops). It is underappreciated to the point of invisibility. It is the cost of doing business.
As public and PE backed companies follow the EBITDA gospel and growth imperative, there’s a simple math - in a world where R&D spend is finite, every dollar paying down the maintenance tail of yesterday's API is a dollar not spent on the feature that shows up in next quarter's earnings call. The ruthlessly rational move means the change log loses that fight every time.
I am nothing but a broken record on this point, but information blocking has reoriented this equation. There are new obligations - now for exchange of all EHI. The surface area that vendors are legally required to support has expanded faster than the engineering budget that any CFO is willing to allocate to supporting it. The two lines do not meet.
Monetized RPA and agentic access are thus inevitable and will become a prevalent form of exchange. If you cannot build out the API surface fast enough to satisfy the regulatory obligation, and you cannot afford the maintenance tail of the API surface you do build, the path of least resistance is to let a third party do it for you, riding on top of the UI you already maintain for clinical users.
An RPA agent driving that UI is, from the vendor's perspective, free regulatory compliance via someone else's R&D budget. And if you can charge that third party for the privilege of using your UI as their integration layer, the math goes from "barely tolerable" to "actively attractive."
This is the equilibrium the surface area of support and our regulatory prerogatives are pushing us toward. It’s debatable it’s an ideal one! But every unsinkable ship eventually meets its iceberg, and the vendors have noticed they can sell seats on the lifeboats.
Dev Docs Addendum
While we’re here (in the athenahealth API change log), I’d be remiss to not mention things I thought were cool.
