You bought a suite. You got six apps.

Private equity spent the last eighteen months buying field service software. Vertical SaaS ran 46 to 54 percent of all SaaS M&A between January 2025 and May 2026. The deal announcements all say "platform". The users, meanwhile, are still relearning how a table works every time they click from leads into invoicing.

Almost nobody writes about what happens to the interface after the deal closes. I have spent more than two years on exactly that part.

Six products, six dialects

The portfolio I work across is six field service management products: tree care and landscaping, home services, property restoration, flooring, pest control, and customer messaging for service businesses. I lead the design across them, with two product designers I lead and mentor.

Each of those products grew the way successful vertical software always grows: feature by feature, customer request by customer request, over years. Each one carried its own buttons, its own tables, its own forms, modals and navigation. Nothing was wrong with any single screen. Everything was wrong with the sum.

Inside one product, users relearned interaction patterns every time they crossed from leads into invoicing, or from scheduling into the warehouse. Across products, there was no shared vocabulary at all. And the debt compounded: every new feature added another local answer to a question that had already been answered five different ways.

The fast option

The fast option, and the one everyone would have understood, was to restyle each product on its own terms. A per-module visual refresh. Individual sections could ship faster and independently, each team on its own schedule, with nobody waiting on a shared system to catch up.

I rejected it. Fragmentation was the root cause, not a symptom. The jarring transitions, the mounting design debt, the slow development cycles and the inconsistent handoff all traced back to the absence of one shared foundation. A per-module refresh would have produced six better-looking versions of the same problem. On one product alone, at fifteen-plus modules and fifty-five-plus report types, module-by-module styling would have recreated the exact debt the project existed to pay down.

So all six were rebuilt against one design system. One component vocabulary, one visual language, one set of interaction patterns, across web and mobile.

What that actually meant

The scale is the point, so here it is. On the tree care product, a full redesign spanning twenty-plus web modules and a crew mobile app of 145-plus screens, with the office platform and the field app finally feeling like the same product. On the home services product, fifteen-plus modules and fifty-five-plus report types. On the flooring product, eighteen-plus modules. The restoration product was reorganised around its lead-to-cash lifecycle, with web and mobile on the same system. The pest control technicians' app got its information architecture rebuilt around four permanent navigation pillars instead of a flat list of modules.

The payoff is that a pattern gets solved once and applies everywhere. Components, patterns and fixes propagate across the portfolio instead of being rebuilt per product.

The cost is independence

Here is what the consolidation decks never mention.

Standardising takes away each product's ability to move on its own. And every one of the six needed patterns no shared system carries out of the box. The messaging product had chat states, unread messages, message groups and a chat sidebar the system held no opinion about. The tree care product needed its own green industry iconography.

That gap is exactly where one-off UI walks back in. A designer under deadline improvises the chat sidebar on one screen, it ships, another screen copies it slightly differently, and six months later you have a fresh system with the original disease.

So those extensions were built as named components inside the system, as local libraries extending the shared one, rather than improvised per screen. Domain-specific patterns became reusable assets instead of the first cracks in a new foundation. Otherwise you have rebuilt the original problem with better spacing.

What I would tell anyone holding a roll-up

Acquisition math assumes the products become a suite. Shared customers, cross-sell, one login, one brand in the sales demo. All of that has to happen in the interface, and none of it happens there by default.

It is a design problem, not an integration ticket. It needs a single system, somebody with the authority to say no to per-product exceptions, and a way to say yes to the ones that are real, by building them into the system rather than around it.

You bought a suite. Until someone does that work, you own six apps.