Buy and build: consolidating acquired software platforms

Buy and build consolidation is what happens to the software when a platform company keeps acquiring. Each add-on arrives with a product, a data model, a team and a customer list, and the platform has to make them one business without stopping any of them. The work is repetitive by design: an architecture decided once, and a playbook run once per add-on.

Serial acquisition is the normal case. Bain & Company's report of 25 February 2019 on buy-and-build found that in 2003, just 21 percent of all add-on deals represented at least the fourth acquisition by a single platform company, that the number was closer to 30 percent in recent years, and that in 10 percent of cases the add-on was at least the tenth sequential acquisition. A platform that plans for one add-on and gets seven is the case this page is written for.

What architecture survives the tenth add-on?

The architecture that survives the tenth add-on is a shared layer for the functions every product has in common, with product-specific features left in the product that has them. Every add-on connects to the shared layer on arrival and keeps its own features until there is a reason to move them.

Layer	What goes in it	Why it is shared
Identity	One login, one user directory, one permission model	Customers of any product get one account; the platform can sell across products
Billing	One invoicing and subscription system	The fund sees one revenue system; cross-selling produces one invoice
Customer data	One customer and account record, with each product's data linked to it	Reporting can answer "how many customers use two products" without a spreadsheet
Reporting	One data export and one dashboard feed	The quarterly report to the fund reads from one place
Product features	Left in each product	Moving them is expensive, and the deal case rarely needs it

This is the federate shape from merging two codebases after an acquisition, applied repeatedly. It differs from absorbing every add-on into one codebase, which is the instinct of a platform whose first product is strong. Absorbing works for the first add-on and slows with each one after, because every absorption is a full migration of a product's behaviour, and by the fourth the surviving codebase is carrying the accumulated compromises of three.

Reveneau builds the shared layer for a buy-and-build platform as a fixed scope, specifying each interface (identity, billing, customer record, reporting) and writing an evaluation suite from that specification before the first add-on connects, so every later add-on is checked against the same suite and the fund sees the same evidence each time. The pillar guide to technology after the deal sets this among the four phases of post-deal work.

Why does the decision have to come before the first add-on?

The decision has to come first because the first add-on sets the pattern by default if nobody sets it on purpose. A bridge built for add-on one (single sign-on plus a nightly data copy) becomes the model for add-on two, and by add-on four the platform is maintaining four bridges to four products, each built differently, with a customer record that exists in five places.

The order of work that avoids that is:

1. Before the first add-on closes, record the architecture decision in writing: shared layer, which functions it holds, and the rule that add-ons connect to it rather than to each other.
2. Build the shared layer against the platform's own product first, so it exists and is proven before any acquired product touches it. This is the step most often skipped, because the platform's own product does not seem to need it.
3. Connect the first add-on using the playbook below, and treat it as the test of the playbook rather than as a one-off.
4. Fix the playbook with what the first add-on taught, before the second closes.

BCG's survey of 100 senior private equity investors, published 7 January 2026, found that 90 percent cite competing priorities as the top blocker to digital transformation. A shared layer built before it is urgently needed is the work that loses to competing priorities, and it is the work that decides whether add-on seven takes a quarter or a year.

What does the per-add-on playbook contain?

The playbook is the same six steps for every add-on, and the value of running it identically is that the board can compare add-ons against each other.

1. Diligence output to integration backlog. The add-on's technical due diligence report is converted into tasks the way turning the diligence report into the first-year plan describes, with the shared-layer connections added as tier-two items.
2. Identity first. The add-on's users move to the shared directory. Customers see one login within the first quarter.
3. Customer record second. The add-on's accounts are linked to the shared customer record. From this point the fund can see cross-product customers.
4. Billing third. The add-on's subscriptions move to the shared billing system. This is usually the slowest step, because contracts and pricing vary, and it is the one that produces one invoice.
5. Reporting fourth. The add-on's product data feeds the shared reporting layer, so the quarterly report reads from one place.
6. Features stay, unless a written reason moves them. Feature consolidation is a separate decision with its own business case, taken per feature, and never a default.

Each step has a dependency count (how many of the add-on's behaviours still run outside the shared layer) that falls to zero, and the board sees that count per add-on.

How does team structure change with each add-on?

Team structure changes with each add-on because systems copy the organisations that build them. Conway's law, stated by Melvin Conway in 1968, is the reason a platform with eight separate product teams and no shared-layer team will have eight separate products and no shared layer, whatever the architecture document says.

The structure that matches the shared-layer architecture is one team that owns the shared layer and product teams that consume it. Each add-on's engineering team becomes a product team on arrival, keeps its product, and connects to the shared layer through the playbook. The shared-layer team grows slowly and deliberately, and it is the team the fund should protect from being borrowed for feature work.

Two rules from the scaling engineering teams guide apply with extra force here. Brooks's law, from 1975, says adding people to a late software project makes it later, and an add-on integration running late is where a platform most often adds people. And coordination overhead grows with every team that has to talk to every other team, which is the cost the shared layer exists to cap: product teams talk to the shared-layer team, and not to each other.

What should the fund see each quarter?

The fund should see one table with a row per add-on, and the same columns for every row.

Column	What it shows
Add-on and close date	Which acquisition and when
Playbook step reached	Identity, customer record, billing, reporting, done
Dependency count	Behaviours still running outside the shared layer, falling to zero
Delivery measures	DORA's change lead time, deployment frequency, change fail rate, failed deployment recovery time, for that product
Cross-product customers	Customers using this add-on's product and at least one other, which the shared customer record makes countable

The last column is the one the investment case cares about, and it is only countable once the customer record step is done. That is the argument for the order of the playbook: the fund's own measure of the buy-and-build thesis depends on step three.

Reporting engineering progress to the fund gives the full quarterly format, and the DORA measures are described there. For a platform with several add-ons in flight, the delivery measures per product show which integration is degrading delivery and which is not.

What are the failure modes specific to buy and build?

Three failures are specific to the serial case.

The absorb trap. The platform absorbs add-on one into its product because it is small. Add-on two is bigger and is absorbed anyway because that is now the pattern. By add-on four the surviving codebase carries four data models' worth of compromise, and every new add-on takes longer than the last. The shared layer avoids it by leaving features where they are.

Bridges instead of a layer. Each add-on gets a point-to-point connection to the platform product, built quickly. Nothing is shared. The customer record exists in n places, and reporting is a spreadsheet. The layer costs more than the first bridge and less than the fourth.

The shared-layer team borrowed for features. The team that owns identity, billing and the customer record is small and skilled, and every product team wants it. Once it is lent out, the next add-on's integration has nobody to connect to. The operating partner's job is to keep that team on the layer.

Bain & Company's press release of 23 February 2026 says holding periods for buyout funds now sit at seven years and that typical deals need 10 to 12 percent annual EBITDA growth to return 2.5x. A buy-and-build platform produces that growth from cross-selling and from the margin of running one business instead of seven, and both depend on the shared layer being built. If you would rather have it built by a team that takes the outcome, building with investors and their portfolio companies is how we do that.