In a single acquisition, the question is often how you merge two organizations. In buy-and-build, that question is already misframed before you start. A platform making its fifth, sixth, or tenth add-on doesn't have a single integration issue but needs a repeatable pattern — and that pattern only works if it distinguishes between what must be assessed anew each time and what remains structurally separate.
A platform company in a buy-and-build strategy is usually not the party that changes. The add-on is adapted to the platform, not the other way around. That seems simpler than a merger of equals, but it invites an assumption that isn't always correct: that everything different about the add-on must be corrected to the platform standard. Some differences are noise. Other differences are precisely the reason the company was worth buying. A sales process that deviates from the platform may be a mistake you correct, or a market approach you should preserve. Without explicitly asking that question, you integrate away exactly what you just bought.
By the third or fourth acquisition, the temptation arises to copy the previous plan. That's efficient, but only if the plan itself was correct and if this add-on is sufficiently comparable. Two service companies with a different revenue model, a different customer concentration, or a different degree of staff dependency don't call for the same integration plan with a new name on top. This page covers what to watch for before redeploying an existing plan: which parts are transferable and which are specific to the previous deal.
Buy-and-build involves a number of recurring categories that more often need to stay separate than be merged. Customer relationships built around an individual person rarely survive a quick handover to a platform account team. Brands with their own name recognition in a region or niche lose value if they disappear too quickly under the platform name. Compensation structures that tied the add-on's management to the company backfire if replaced immediately. The question is not whether such elements will ever integrate, but when, and whether the reason for it is a genuine synergy or merely the convenience of a single system. An overview of these kinds of choices is on this page.
The risks of integrating too quickly or too broadly are greater in buy-and-build than in a single deal, because the mistake repeats with every subsequent add-on. A front-office system that already didn't fit at the first add-on becomes a structural problem by the fifth add-on rather than an incident. Culture integration that causes one company an uncomfortable half year becomes a reputation in the sector across a series of add-ons — and that reputation affects whether the next add-on still wants to cooperate. This page contains the broader analysis of when merging tips over from value creation to value destruction, and that pattern is more the rule than the exception in a platform strategy compared to a one-off deal.
What buy-and-build requires is not one answer to the integration question but a fixed way of asking that question repeatedly. Which systems are shared, which processes remain local, which personnel policy applies platform-wide and which policy stays with the add-on — these are decisions made per component, not once for the entire company. How you build that decision list and what you base it on is on this page. For sectors with their own dynamics, such as construction or the installation industry, additional bottlenecks often apply that the generic decision list doesn't capture; these are described on the pages about stalling integrations in construction and stalling integrations in the installation industry.
Mergerintegration.net does not provide a track record or a team that shows up. It provides the generators for synergy baseline, Day 1 plan, and Day 100 plan, and an integration office that tracks benefit tracking, dependencies, and the decision list — so that the question of what does and doesn't merge is asked anew and in the same way for each add-on. The tool is under development; anyone wishing to use it can sign up for the waiting list.
Once you have determined which parts of the add-on stay separate and which are absorbed into the platform, a follow-up question arises: how much of the work in those parts is actually still done manually, and where that changes once systems are in fact merged. The work scan from FTE TO AI calculates, per task, what portion of the work can be taken over by AI, providing a quantitative picture of the staff capacity behind each of the components you include in your integration plan or deliberately leave out of scope.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.