Case study: a healthcare client's coverage-gap problem, and what came after

A mid-market healthcare services client came to us in early 2023 with what they described as "a reporting problem." Their operations team was spending roughly two days a month building a coverage-gap analysis by hand: pulling claims data from one system, eligibility data from another, benefits configurations from a third, then reconciling all of it in a shared spreadsheet nobody trusted.

They didn't want a platform. They wanted the report to stop being a fire drill.

What they had

Three data sources, two SaaS tools with partial overlap, and one very tired analyst. The SaaS tools weren't bad. They just weren't built for this specific reconciliation, so every month somebody was exporting CSVs and doing the last-mile work in Excel. The numbers were usually right. Usually.

The risk wasn't the tools. It was that a single person held the whole process in their head, and the outputs drove decisions about member outreach.

What we built

A small purpose-built app. Not a platform. Not a "suite." One screen that pulled from the three source systems on a nightly job, applied the client's specific coverage-gap logic, and produced the report as both a dashboard and an exportable file. About six weeks from kickoff to production, running on infrastructure we manage.

We replaced one of the two SaaS tools in the process. The other stayed. There was no reason to touch it.

What changed

The monthly two-day exercise became a scheduled job. The analyst got their week back. More importantly, the logic was now written down in code that we and the client could read, instead of living in one person's head and a spreadsheet with 14 tabs.

That was supposed to be the end of it.

Why it kept going

Once the coverage-gap report was reliable, the client started noticing adjacent problems the old workflow had been hiding. A provider-network audit that used the same underlying data. A member-outreach queue that could be generated automatically instead of assembled by hand. A quarterly compliance export that had been another spreadsheet.

Each one was a small, boring build. None of them were "transformations." Two years in, we run six internal tools for this client on the same managed stack, and their operations team has grown into the work instead of drowning in it.

This pattern isn't unique to us. Retool's 2026 Build vs. Buy Report found that 35% of enterprises have already replaced SaaS with custom software, and 78% expect to build more internal tools in 2026. Newsweek's follow-up on the same shift describes teams quietly rebuilding workflows that used to live in subscriptions.

The implication

We didn't sell this client a partnership. We sold them one report. The partnership came from the report working, and from the next problem being visible once the first one stopped burning.

If you're looking at a build, we'd rather help you scope the smallest useful thing than the biggest impressive one. That's usually where the real compounding starts.