Buy vs build, inside a portfolio

The standard buy-vs-build advice for a single SME is sound: buy the tool unless building it is genuinely core to what makes you different, because engineering time is scarce and a mediocre off-the-shelf tool solved today beats a great bespoke one solved in six months. That advice holds for one business solving one problem once.

It holds much less well the moment a second brand in the same group needs the same capability. At that point the comparison isn't "buy this tool versus build it for one brand" — it's "keep paying for two separate subscriptions with two separate data silos versus build the capability once and let every current and future brand use it for close to zero marginal cost." The economics of build improve every time another brand in the portfolio would otherwise need to buy the same thing separately.

The question that actually decides it

The useful test isn't "is this hard to build" — most things are, to varying degrees. The useful test is whether the capability is a shared primitive that multiple brands will need, or a one-off requirement specific to a single front. Compliance record-keeping, lead routing, customer data handling, and the intelligence layer that turns raw signals into decisions are shared primitives almost by definition — every brand in the group needs some version of them, so building once and reusing is close to a free decision once the first version exists.

A bespoke landing-page animation for one brand's launch, on the other hand, is a one-off. Building infrastructure around something only one front will ever need is the opposite mistake — it's over-engineering dressed up as strategic investment. The discipline is in telling the two apart honestly, before the build starts, rather than justifying a build after the fact because it was interesting to work on.

Where buying still wins, even in a portfolio

• Anything genuinely commoditised. Payment processing, transactional email, cloud hosting — the market has already solved these to a standard that in-house rebuilding rarely beats.
• Anything used by exactly one brand, with no clear signal a second brand will need it. Building ahead of real demand is a bet, and a bet made with engineering time instead of cash is still a bet.
• Anything where the buying decision is reversible and the build decision isn't. A subscription can be cancelled next month. A bespoke system becomes a maintenance obligation the moment it ships.

Where the portfolio changes the answer

Two failure modes sit on either side of the right answer. The first is building bespoke infrastructure for something only one brand will ever use — that's expensive optimism, and it shows up later as unmaintained code nobody wants to touch. The second, less obvious failure mode is continuing to buy separately for something the portfolio has quietly needed several times over — that's the more common mistake in a growing group, because each individual purchase looks reasonable in isolation and nobody adds up the total cost of overlapping subscriptions doing similar jobs.

The fix for the second failure mode isn't a rule, it's a habit: every time a brand reaches for a new tool, ask whether this is the first time the portfolio has needed this capability or the third. The answer changes the decision, and it's only visible if someone's actually looking across brands rather than deciding brand by brand in isolation.

A pattern worth watching for

The signal that a buy decision should flip to build rarely arrives as a single dramatic moment — it arrives as a pattern, quietly, across several unrelated procurement conversations. A brand needs a way to track compliance renewal dates. A few months later, a different brand needs almost the same thing, described slightly differently because nobody connected the two requests. Left unexamined, that pattern produces two separate subscriptions, two separate data models, and two teams solving the same problem without either realising the other has already spent money doing so.

Catching the pattern requires someone whose job includes looking across brands rather than within any single one — which is itself an argument for keeping a small amount of shared technical judgement above the level of any individual brand, even inside a structure that otherwise pushes decision-making down and out to each front. That's not a management layer in the sense described elsewhere in this journal; it's closer to a standards function, checking whether a request is genuinely brand-specific before it turns into a bespoke purchase or a bespoke build.

Buy vs build isn't a one-time decision. It's a question that should get asked again every time the portfolio grows, because the right answer for the first brand isn't necessarily the right answer for the fourth.

Building the shared engine this way — treating genuine cross-brand primitives as build candidates, and treating everything else as a buy — is slower to set up than either extreme on its own. But it's the only version of the decision that actually accounts for the fact that a portfolio, unlike a single business, gets to amortise a build decision across more than one P&L. That's the entire argument for building a shared spine in the first place, and it only holds if the buy-vs-build test gets applied honestly, brand by brand, rather than assumed.

None of this is a case for building everything in-house out of principle. Plenty of the group's infrastructure genuinely is bought — cloud hosting, payment rails, transactional email — because building those in-house would be optimism, not strategy. The discipline is knowing which category a given decision falls into before committing engineering time to it either way, and being willing to revisit that categorisation as the portfolio grows and the maths quietly shifts underneath a decision made a year earlier.