Built by People Who Never Made Payroll: The Operator Gap in Practice Software

Nobody who builds practice software has ever floated payroll from a personal account. Why upgrades serve the median, and why the last mile is yours.
Updated July 2026

9 PM on a Thursday

A practice owner is moving money from a personal account to cover tomorrow’s payroll, because three payers slowed down in the same month and every report said everything was fine. Revenue looked normal. The schedule was full. And the account that pays people came up short anyway, because you can’t make payroll with revenue; you make it with cash, and nothing on any screen was watching the difference. Somewhere far away, the people who built that software are asleep, and they’ve earned it. They did their jobs well. Their jobs have just never included this particular 9 PM.

Who Actually Builds Practice Software

Practice management and EHR products are built by capable engineers and product managers working from ticket queues, usage analytics, and roadmap reviews. They’re good at what they do. But walk the halls of any practice software company and try to find someone who has personally signed a clinic’s lease, guaranteed its line of credit, floated its payroll from a family account, or sat across from a therapist explaining why the paycheck is three days late. You’ll mostly come up empty. Nobody in the building is on the hook, and it shows up exactly where you’d expect: in what the product considers urgent.

This isn’t an insult to the builders. It’s a fact about distance. The person who designs the claim workspace experiences a denial as a status value. The owner experiences it as a mortgage payment that arrived dressed as a work queue. Both descriptions are accurate. Only one of them was ever going to shape the roadmap.

Read the Release Notes Like an Operator

Pull up the upgrade announcements from any major system, several years’ worth, and sort what shipped into piles. The piles are always the same three. Compliance work the regulators required, which is mandatory and eats quarters of engineering time before a single customer request gets touched. Features the broadest slice of the customer base asked for, which is rational, because a vendor serving tens of thousands of practices must build for the middle of that distribution. And parity with whatever competitors demonstrated last quarter, because sales calls are won on checklists.

Every pile is reasonable. Now notice what’s never in any of them: the upgrade that encodes your collection policy. The release that enforces your documentation standard. The feature that watches your Tuesday-morning reconcile and calls you when the chain breaks. The roadmap can’t contain those, because the roadmap has never met your practice. It ships the median’s needs on the median’s schedule, and your operating doctrine isn’t the median’s need. It’s yours.

Structure, Never Villainy

It’s tempting to read all this as an accusation, so let’s kill that reading directly. No vendor is hiding the good version from you. The economics of software require building for the middle: that’s how a product stays affordable for a three-provider practice and functional for a three-hundred-provider group at the same time. The certification burden is real and enormous. The backlog triage is honest. Expecting a vendor’s release cycle to encode your specific operating behaviors is a category error, like expecting the company that built your truck to plan your delivery routes. They built you a very good truck. The routes were always going to be your job.

The Sentence Worth Taping to the Monitor

Here it is, and it applies to every system on the market, including the good ones: no practice software, out of the box, drives the business behaviors your practice needs. Not one. The software records what happens. Whether the right things happen, the card captured at booking, the note signed same day, the claim out within 24 hours, the denial worked this week, the gap noticed this morning, is decided somewhere else entirely: in policies you write, defaults you configure, automation you add, and numbers you actually watch. Out of the box, every practice runs on the personalities of its staff. That’s the factory setting, everywhere.

The Last Mile Belongs to You

Once you accept that the last mile was never coming in an upgrade, the path gets practical, and it’s shorter than it looks. Write the policies down, because a rule that lives in a head isn’t a rule; the variability guide covers why this is worth real money. Push the repeatable work onto machines to the 80% standard, so the behaviors stop depending on who showed up. Put your people on the work that deserves them, which is the whole argument of the robots guide. And watch the ten numbers weekly, with names attached, so drift gets caught in days instead of quarters.

None of that ships in a release. All of it can be built on top of the system you already own, which is precisely the point: the software was always the foundation, and foundations don’t finish houses.

Where to Start

Start by asking one question about your own operation: which behaviors that decide our cash are currently enforced by software, and which are enforced by hoping? The second list is your build list. If you want to see what the finished last mile looks like before you build anything, grab 30 minutes with us: prep nothing, and we’ll show you the report views and automations we run on top of a practice’s existing system, from real operations, built by people who have made the 9 PM transfer and decided never to make it again.

Read next