A great many enterprise software categories were not designed; they were deposited, layer by layer, as each new need washed through. A team needs to track one thing, and a tool appears. A second need follows, and a second tool, bought by a different person under a different budget. The work overlaps heavily underneath — the same customers, the same records, the same workflow viewed from a slightly different angle — but the tools do not, and the typical mid-market firm ends up running several side by side, reconciled by spreadsheets and the analysts who keep them current. The landscape is wide, capable and shallow: many good products, almost no platforms. That is the most legible buy-and-build setup in enterprise software, and the thesis behind much of what we look at.

Governance, risk and compliance software is the example we know best, so we use it to illustrate — but the pattern is general, and recurs wherever obligations or needs arrive one at a time onto the same population. The discipline that turns it into value is the same regardless of category.

Why the work itself invites consolidation

The case for consolidation is not the generic one — fewer logos, one invoice. It rests on a specific feature of how these markets are structured: the tools operate on shared underlying objects. The same supplier that sits in one tool is a line in another’s register; the same control a third tool tests is the one a fourth references. When something has to be assessed end to end, the firm needs the affected entities, the implicated parties and the relevant records in one coherent place — not scattered across four subscriptions that disagree about what a “supplier” or a “customer” even is.

In the GRC case this is acute, because regulation writes the overlap explicitly. The same third party that sits in a firm’s vendor-risk tool is also a line in the register of contractual arrangements that DORA, Regulation (EU) 2022/2554, requires every in-scope financial entity to maintain at entity, sub-consolidated and consolidated levels under Article 28(3). The same control a testing tool exercises is the control a policy references and an incident invokes. But you do not need a statute for the structure to hold — any market where the tools describe the same world from different windows is a candidate.

Fragmented tooling forces firms to maintain the same entities, records and evidence several times over, in formats that do not reconcile. A platform that holds them once removes that duplication at the root. The buyer stops paying people to keep four databases agreeing with each other; the owner inherits a footprint that widens with every adjacent need a customer must meet.

The prize is not a tidier vendor list. It is a single description of the customer’s world that every workflow can draw on at once.

What separates a build from a roll-up

Most roll-ups in fragmented software fail for the same reason: they acquire revenue without acquiring coherence. Logos accumulate; the products never become a suite. The discipline that distinguishes a build is unglamorous and largely architectural.

  • A shared data model, so an entity, a record or an event is defined once and recognised by every module.
  • An integration roadmap with the authority to retire overlap, not merely route around it.
  • A cross-sell motion in which a customer who arrives for one need is met with the next before a rival is.
  • A pricing logic anchored to the breadth of the suite, so it is worth more than the sum of the tools it absorbs.

The demand is supplied by whatever drives the category — in GRC it is the regulatory calendar, which keeps tempting the market to spawn yet another point tool with every new regime; in other markets it is a new channel, a new data source, a new operating requirement. The consolidator’s task is always the same: absorb the incoming need into an existing model rather than answer it with a fresh acquisition that never integrates.

The honest caveat, and the discipline it implies

The fragmentation is genuine; the headline market numbers usually are not a basis for underwriting. In GRC, analyst houses disagree sharply on the prize — MarketsandMarkets sizes enterprise GRC at USD 20.56 billion in 2025; Grand View Research projects USD 134.86 billion by 2030. The gap is not error but definition — software alone versus software plus services, narrow scope versus everything adjacent. The same trap exists in any fragmented category: an acquirer who underwrites the larger number and builds for the smaller one will overpay. The work is to buy where the shared-data thesis actually holds, integrate with the patience the architecture demands, and let the underlying needs — which arrive on their own schedule, whatever the sentiment — accumulate against a single platform rather than across a portfolio of logos. That is the platform these markets are missing, and the one Northstone sets out to build.