Buy-and-build: which of the acquired apps do you keep?
Every add-on brings its own billing, scheduling and reporting systems. Twelve acquisitions in, the platform runs five of everything. ARC shows what each one actually does, so the keep, merge or retire call rests on evidence.
Five of everything
A roll-up buys growth one add-on at a time. Each brings a working business and the systems that run it: a practice-management tool, a homegrown billing app, a reporting database someone built in 2014. Integration plans assume these get consolidated. Most of them never are, because nobody can say with confidence what the third billing system does that the first one doesn't.
Names don't tell you overlap
Two systems called "Billing" may share almost nothing. One handles insurance remittance with forty state-specific rules; the other sends invoices. A system called "Portal" may be quietly running a pricing engine. Comparing feature lists in a workshop misses both.
Overlap lives in business rules and data, not in application names.
What ARC does
- Puts every acquired app on one map. Each application is placed on the platform's business capability map, so two systems on one capability is visible at a glance.
- Compares what they really do. Discovery extracts each system's capabilities and business rules with file and line citations, so the differences between two billing systems are specific, not anecdotal.
- Prices the consolidation. Each keep, merge or retire decision carries the rules that would have to move, which is what the integration budget actually depends on.
What you get
Timelines depend on access to code and people; we confirm them on the scoping call.