If you run a small-cap buy-and-build group, you probably have a technology problem that gets worse with every deal.
Each acquired business brings its own ERP, spreadsheets, workarounds, point tools, and habits. The usual answer is to force everything onto one shared platform. Dynamics, SAP, NetSuite, or a vertical tool.
That answer can work. It is also often slow, expensive, and incomplete. You spend years bending generic software around operations that were never designed for it.
The result is familiar. A patchwork that works well enough, held together by admin effort and knowledge in people's heads.
The better answer for many groups is to own the operating layer. Not on day one. Not for every business. But once integration drag becomes the constraint, a bespoke AI operating system starts to look practical.
Right Fit
This does not apply to every buy-and-build. It is a bad first move after one or two acquisitions. At that stage, a standard ERP usually does enough.
The case changes once the group has several acquired businesses and a live pipeline. At that point, the cost is no longer just software. It is the repeated labour of integration, reporting, scheduling, billing, handovers, and exception handling.
The strongest fit is usually a group with:
- Revenue of roughly £10m to £30m.
- EBITDA of roughly £2m to £3m.
- Several acquired businesses with overlapping systems.
- Heavy back-office work in fields such as facilities, logistics, healthcare services, or field services.
- An active acquisition pipeline.
Single-site businesses, passive holding groups, and already lean back offices should probably wait. Large vendors will add more AI to their products, and for many businesses that will be enough.
Cost Shift
The build case has changed because the cost of software delivery has changed.
AI coding agents have cut the time needed to write, test, and maintain internal software. Work that once needed a large team and a multi-year budget can often be done by a small pod in months.
This does not remove engineering judgement. It raises the return on good judgement. A small team that understands the business can now ship useful internal systems at a pace that was not realistic a short time ago.
That is the core shift. Bespoke software used to be a luxury for the largest companies. For the right group, it can now be the cheaper path to real operating change.
AI OS Meaning
An AI operating system is not a chatbot layer on top of old tools. It is a focused operating stack built around how the group actually works.
It needs two things above all else. First, ownership of the data layer. Second, a system of record that AI agents can read from and write to safely.
Traditional ERPs hide data behind rigid schemas, proprietary APIs, and middleware. That makes automation slow. AI can reason well over messy work, but only when it can reach the right context.
Back-office work is full of repeatable judgement. A person pulls data from one place, interprets it, makes a decision, updates another place, and leaves a trail that is often incomplete.
A well-designed agent can do much of that work if the data layer is clean, accessible, and controlled by the business.
Data Advantage
The main prize is not the first workflow you automate. It is the data trail each workflow creates.
Calls, emails, documents, internal messages, notes, and decisions often never reach the ERP. The business loses context every day. People leave and judgement leaves with them.
An owned AI OS can record the decision, the source data, and the reasoning. That creates a knowledge base that improves with use.
Take scheduling in field services. A poor scheduling decision can be reviewed against the facts used at the time. The system can learn why the decision failed and update the rule or agent behaviour. That judgement is then available across the group.
This is where the advantage compounds. Each workflow creates cleaner data. Cleaner data makes the next workflow easier to automate. Each acquired business adds volume, edge cases, and operating knowledge.
Acquisition Flywheel
Buy-and-build groups already understand compounding. The AI OS gives them another compounding asset.
- Acquire businesses at sensible multiples.
- Move core workflows onto the owned operating layer.
- Use the platform to cut admin drag and improve service.
- Turn the improved margin into higher EBITDA.
- Use the stronger base to fund more acquisitions.
This is more durable than basic back-office standardisation. Shared finance and HR help. They do not create much proprietary value.
An owned operating layer can. It becomes part of the integration playbook. It also becomes part of the equity story. The group is no longer a set of companies sharing software. It is an operator with its own system, data, and methods.
Vendor Question
The fair objection is simple. Why not wait for Microsoft, SAP, and vertical SaaS vendors to add these features?
For many businesses, that is the right call. The issue is value capture.
A large share of operating cost sits in labour that bridges systems. People interpret messy inputs, move data, chase exceptions, and keep service levels up. As vendors replace that work with AI, they will price for the value they create.
If the group owns the AI layer and the data layer, more of that value stays inside the business. The group also controls the customer experience and can move before large vendors serve its narrow use case.
That does not make vendor software bad. It means dependency has a price.
Team Shape
This does not require building a large product organisation inside a services business.
The right starting point is often a small embedded pod of three or four people. They should sit close to operators, not off to the side as an outsourced build team.
The lead role matters most. This person needs product sense, technical judgement, and enough operational credibility to change how work gets done.
The build is only half the job. The other half is adoption. Process redesign, retraining, role changes, and controls must be part of delivery from the start.
Get that wrong and the software ships but the business carries on as before.
Start Point
The right question is not whether every buy-and-build group needs an AI OS. They do not.
The right question is when the cost of the existing patchwork becomes higher than the cost of owning the operating layer.
If the group is still early, buy the standard tool. If the group has several acquisitions, high admin load, and another set of deals coming, the answer may be different.
At that point, the operating system is no longer an IT project. It is an acquisition asset, a margin asset, and a knowledge asset.
That is the moment to start.