What buy-and-build means for your integration approach

A platform strategy is not a series of separate deals that happen to share an owner, nor is it a merger of equals. That makes the integration question different from a single acquisition. With every new add-on, the same choice repeats itself: what do you merge with the platform, and what do you deliberately leave separate. Buy-and-build does not reward maximum integration. It rewards a consistent, repeatable way of making that choice, deal after deal.

Why "always integrate fully" doesn't work here

In a platform strategy, the temptation is great to push every add-on into the platform's systems, processes and culture as quickly as possible. That looks efficient, but it is also where value disappears. An add-on that was bought for a specific customer relationship, a niche capability or local market knowledge loses exactly that when integration goes too far. The question of whether something should be merged is not an exception to the rule in buy-and-build. It is the rule. Some parts strengthen the platform through merging, while other parts are weakened by that very same move. When does integrating destroy value, and how can you tell sets out where that boundary usually lies.

What makes platform logic different from a one-off merger

In a single acquisition, you ask the integration question once, extensively, with a great deal of attention to that specific moment. In buy-and-build, you ask a comparable question repeatedly, often under the time pressure of the next deal already in the pipeline. That calls for an approach that can be repeated without reinventing the wheel every time. A synergy baseline, a Day 1 plan and a Day 100 plan are then not one-off documents, but a template you fill in for each acquisition. How that works in practice is shown at how do you reuse an integration plan. The repeatability lies not in copying outcomes, but in going through the same structure of questions again.

What you typically leave separate in a platform strategy

In buy-and-build there are a few recurring categories where leaving things separate occurs more often than merging. Customer relationships built around a person or a specific team tolerate little disruption. Operational systems that have just been set up for a specific workflow often cost more to replace than they yield in scale benefits. Brands with their own recognition in a specific niche lose value if they disappear into the platform brand. This is not an exhaustive list or a fixed rule, because it depends on why the add-on was bought and what that acquisition needs to keep doing within the larger whole. What do you deliberately leave separate, and how can you tell in advance explains how you can recognise this per case in advance, rather than discovering it afterwards.

The systems that often stay better left alone

Within a platform strategy there is a persistent pressure to consolidate systems: one ERP, one CRM, one reporting structure. That pressure is understandable, since managing multiple systems costs time and overview. But consolidation is not a goal in itself. A system that fits well with a specific business process of the add-on can destroy more value through replacement than it delivers in ease of management. The question is not whether consolidation is possible, but whether the underlying process is genuinely the same. When it is not, a system sometimes stays better left as it is, even if that feels inefficient at first glance. See which systems are better left as they are, and how can you tell for the considerations involved.

A decision list per component, not per deal

The core of a workable buy-and-build approach is that the decision about integration is not made at deal level, but at component level. Finance, IT, sales, HR, brand, customer relationships: each component deserves its own consideration, with its own arguments for merging or leaving separate. A decision list that records this component by component prevents one argument for integration from automatically dragging along all the other components. How you build up that list and where the considerations typically differ is set out at how do you decide per component whether or not to integrate. For the broader platform context, including how repetition and customisation relate to each other, there is also an in-depth page at what does buy-and-build mean for your integration approach, in detail.

The three generators and the integration office described here are tools for structure: they raise the question of whether or not to integrate for each component anew, they keep track of which synergies were assumed and which actually occur, and they record dependencies between components. There is no completed engagement that this tool draws on; it organises your own considerations, it does not replace them. This tool is under development. Those who want to work with it once it becomes available can sign up for the waiting list.