The conventional wisdom is that a dental or medical group with fifty locations is far ahead of the solo practice down the street on AI. It has scale, a central office, negotiating power, a technology budget, maybe even a VP of innovation. More resources, more sophistication, more maturity — obviously.
I think that’s often wrong, and sometimes backwards. On the Healthcare AI Maturity Model, a fifty-location group can sit further from AI-Native than a two-provider practice. Not despite its scale. Because of how it got that scale.
Scale multiplies whatever you already were
Most groups grew the same way: by acquisition. They bought practice after practice, and each one arrived as a going concern — with its own phone system, its own scheduling software, its own front-desk habits, its own pile of tools someone had adopted along the way. The group didn’t build one operation fifty times. It collected fifty different operations and put them under one logo.
That matters because of what scaling actually does. Scaling doesn’t create coherence; it multiplies whatever was already there. If each location arrives with a disconnected stack, the group doesn’t scale AI — it scales AI Sprawl. Fifty locations, fifty stacks, none of them talking to each other, and now a central team trying to make sense of the mess. A group doesn’t scale its AI. It scales its sprawl.
The single practice has one operation, one stack, one owner. The group has none of that unity. Most groups don’t operate one fifty-location organization; they operate fifty one-location organizations with a shared logo — dozens of systems to reconcile, no shared operating layer, and (as with most large organizations) no one who actually owns it end to end. On every dimension that determines the climb to Stage 4, scale has made things harder, not easier.
Why scale feels like progress but isn’t
The trap is that scale produces all the signals of maturity while hiding the absence of it. The group has more AI tools than any single practice — more logins, more vendors, more pilots, a bigger spend. On a slide, that reads as “ahead.” But tool count was never the measure. The measure is whether the operating layer functions as one connected system, and by that measure the group is often behind, precisely because it has more disconnected pieces to unify.
This is the same plateau every organization hits, in an unusually stubborn form. A solo practice with three disconnected tools can rip them out and start over next week. A fifty-location group with fifty entrenched stacks, fifty sets of staff habits, and fifty local managers who each like their own setup faces a change-management problem that dwarfs the technology one. The group has more resources to spend on the climb — and a far steeper climb to spend them on.
The mistake underneath the mistake
The root error is treating an acquisition as a financial event rather than an operational one. When a group buys a practice, the deal team integrates the P&L, the billing, the branding — and leaves the operating layer alone, because “it’s working.” So the sprawl compounds with every acquisition. The more successful the roll-up strategy, the worse the AI-maturity problem gets. Growth and coherence move in opposite directions.
That’s why the groups winning market share can be the ones losing the AI-native race. Their operating model rewards adding locations, not connecting them — and connecting them is the entire task.
What the framework says to do instead
The prescription follows directly, and it’s specific to scale.
Stop buying tools at volume; build one operating layer. The advantage of being a group isn’t better per-seat pricing on ten products — it’s the ability to run one connected operating layer across every location. That’s the only version of scale that compounds. Standardize the patient journey — contact, scheduling, intake, follow-up, payment — as a single system, centrally owned, that every location runs.
Give the operating layer a real owner. The group’s structural advantage over the solo practice is that it can actually justify a dedicated owner of the operating layer — a role a two-person practice can only ever do part-time. Used well, that’s how a group turns its scale from a liability back into an advantage.
Change how you integrate acquisitions. The moment to prevent sprawl is at the deal. Fold new locations onto the shared operating layer as part of integration, the way you already fold in billing. An acquisition that keeps its own disconnected stack isn’t integrated; it’s just consolidated on paper.
Do those three things and scale becomes what everyone assumed it already was: an advantage. Skip them and every acquisition digs the hole deeper.
The prediction
Here’s the testable version of all this. The next generation of winning groups won’t differentiate themselves by negotiating lower per-seat software prices across more locations. They’ll differentiate themselves by running every acquired practice on one operating layer — and the gap between the groups that do and the groups that don’t will widen every year, because coherence compounds while sprawl only accumulates. Watch which groups treat their next acquisition as an integration problem rather than a purchase. Those are the ones that reach Stage 4.
The bottom line
Scale is not maturity. A group that grew by acquisition has, by default, accumulated operations rather than designed one — which means its AI problem is not too little technology but too little coherence, and coherence is exactly what more acquisitions destroy.
The groups that will reach AI-Native aren’t the ones with the most locations or the biggest technology budgets. They’re the ones that realized their scale was working against them, and did the unglamorous work of turning fifty operations back into one. Until then, the solo practice across the street — with its single stack, single owner, and single operation — may quietly be closer to the destination than the fifty-location group that looks like it’s winning.
Frequently asked questions
Why would a large group be less AI-native than a small practice?
Because most groups grew by acquisition, and scaling multiplies rather than unifies: each acquired location arrives with its own disconnected tools and systems, so the group accumulates many operations instead of designing one. On the Maturity Model, what matters is whether the operating layer is one connected system — and a fifty-location group often has fifty disconnected ones, while a solo practice has a single coherent operation.
Isn’t more AI investment a sign of maturity?
No — tool count and spend are not the measure. A group can have far more AI than any single practice and be less AI-native, because maturity is about coherence, not quantity. More disconnected tools is more AI Sprawl, not more progress.
What is the core mistake groups make?
Treating acquisitions as financial events rather than operational ones. Deal teams integrate the P&L and billing but leave each location’s operating layer alone, so sprawl compounds with every purchase. The more successful the roll-up, the worse the coherence problem becomes — growth and coherence move in opposite directions.
How should a multi-location group approach AI?
Build one connected operating layer across all locations rather than buying tools at volume; give that layer a dedicated owner (a role a group can justify and a solo practice can’t); and fold every new acquisition onto the shared operating layer as part of integration, the way billing already is. That turns scale from a liability back into an advantage.
Does this mean scale is always a disadvantage?
Only when it’s uncoordinated. Scale done right — one operating layer, centrally owned, that every location runs — is a genuine advantage, because the group can invest in ownership and architecture a small practice can’t. The disadvantage is specific to scale-by-accumulation, where locations are consolidated financially but never connected operationally.
Read next
- Why Independent Practices May Reach AI-Native First
- The Healthcare AI Maturity Model
- Why Organizations Plateau at AI-Assisted
- Who Owns the Operating Layer?
- Why Healthcare Needs an AI Architecture (Not More AI Tools)