Buy the Tools, Build the System

Ask someone on your team to walk you through how one order, one claim, or one new client request moves from the first email to the moment it closes. You’ll get a tour of five or six applications, two inboxes, and a spreadsheet holding the whole thing together.

Every one of those applications is good. Somebody chose it carefully, the team knows how to use it, and it does the job it was bought to do.

But the spreadsheet is the glue.

That spreadsheet, or the shared inbox, or the whiteboard by the dispatch desk, or the operations manager who keeps the sequence in his head, is where your work lives. It’s the only thing that knows what’s waiting, who has it, what’s overdue, and what happens next. It’s also the only part of your operation nobody sold you, nobody supports, and nobody has tested for what happens when the person maintaining it takes two weeks off.

The buying was sound. Nobody was ever given the job of making your core applications work together, so that job falls to people, by hand, every day. That arrangement has a price, and you pay it in delay and rework instead of on an invoice.

AI is widening the gap it was sold to close

The stack is growing again, and AI is the reason. BetterCloud’s 2026 State of SaaS report has mid-market companies going from 116 applications to 164 in a single year, with AI-powered tools named as the driver.

Evaluated one at a time, every one of those AI tools is capable. Each one is also blind past its own boundary. When looked at as a whole, the pattern is a stack of steps that each got measurably faster, joined by manual spaces that didn’t. It’s progress, but it’s incremental. The spaces between are the limit, and nothing in the stack changes them.

Buy the doing. Build the holding.

Your technology does two different jobs, and the same buying approach won’t serve both.

The first is specialized execution: document generation, transcription, records retention, etc. Buy it unless you have a specific reason not to. Build it if your version of the task is genuinely different from everyone else’s, and that’s true more often than the software industry admits.

The second is how work moves through your business: what a job is, what stages it moves between, who touches it, what has to be true before it advances, what happens when something goes wrong, and where a person can see all of it at once. That part is specific to your business. It’s also the only part that compounds, because every improvement you make to it stays yours.

A plumbing company with twelve trucks doesn’t run on its trucks. It runs on whatever system decides and keeps track of who’s going where, in what order, what’s urgent, and what got promised to whom. Buy better scheduling software, hire two more techs, and something still has to do all of that.

Your applications are the trucks, and they’re good trucks. The system that coordinates them exists too, in some form. The question is whether it’s in a form that can be improved, monitored, or handed to anyone else.

Designing that system deliberately doesn’t mean replacing what you own. The products you already have stay exactly where they are and keep doing what they’re good at. The new layer wraps around them and takes over the coordination none of them was designed to handle. The approach is well established in software engineering: build the new thing around the old one in small pieces, rather than betting the operation on a replacement project.

The coordination layer outlasts the tools

Once coordination lives in a layer you own, your operations stop being disrupted every time the technology moves. A better AI tool is simply an upgrade, rather than a migration.

Tool changes hurt when coordination has grown around the tool. Where that’s the case, the steps people follow, the checks in place, and the handling of exceptions all take the shape of the products a business is using. Remove one of those products and the rules that referenced it stop applying. What replaces them gets worked out again, case by case, over time.

That cost is high enough to change what a business will consider. When a better capability shows up, someone runs the numbers on switching and the answer is to stay put. What makes it unaffordable is the disruption, and the disruption is a property of the arrangement rather than of the tool.

Rules written into a system you own do the opposite. They reference the work rather than the product. Swapping in a new tool changes only what happens at one step. The sequence, the checks, and the exception handling are unaffected, because none of them were describing the tool in the first place.

The objection to building this layer used to be cost, and it was a fair one, because every connection used to be built by hand. That’s changing. The connections between AI tools and business systems have standardized around the Model Context Protocol. Connecting an AI tool to your systems used to mean custom wiring for each connection. Now there’s one standard plug, and anything that uses it can connect to anything else. Anthropic released it, then handed it to a foundation backed by OpenAI, Google, Microsoft, and AWS, so it belongs to no single vendor. A neutral standard means the connections are becoming a commodity, which lowers the cost of the part that used to make this decision hard.

What coordination-by-accident costs

Nothing dramatic happens if the coordination stays where it is. That’s the difficulty with it.

What happens is slower. Each new AI capability gets evaluated as a product purchase, and the good ones get declined because switching costs more than the improvement is worth. Your process knowledge keeps accumulating in people, shaped around tools you may not be using in three years. When the operations manager retires, a decade of judgment about how work moves through your company walks out with her. And when you eventually sell the business, a buyer looks at a stack of licensed tools and pays you nothing extra for any of it.

When NOT to build

Two things make this the wrong move for some businesses.

If your work genuinely lives inside a single system, and your people don’t hop between applications to complete a task, you don’t have this problem. Some businesses are like that. Building a coordination layer over a stack that isn’t fragmented adds a component with no job.

And a layer you build is a thing you own, with an owner’s obligations. It needs documentation, monitoring, and a named person responsible for it. The layer will age. Everything does. What makes a system legacy is that nobody can change it safely, and that happens when nobody understands it, nothing tests it, and the people who built it left. Those are conditions you control, and they cost less to maintain here than anywhere else in your stack, because this layer is the smallest thing you own. It holds rules about how work moves, not records, not accounting, and not documents.

Four questions for anything in your stack

1. If this tool disappeared tomorrow, what else would stop working? A short list means the tool is doing its job and nothing else. A long one means your coordination has grown around it.
2. Does anyone outside this company do this exact task the same way we do it? If yes, buy it. Uniqueness is the only argument for building, and most tasks aren’t unique.
3. Where does the work wait between steps? If the answer is a spreadsheet, an inbox, or a person, you’ve found the candidate. Those three answers are your coordination, running in a form nobody designed.
4. If AI could handle half of a step next year, would we have to rebuild the workflow to let it? A yes means the workflow is shaped around today’s labor, and it will need rebuilding each time that changes.

Most of the stacks I look at fail the fourth question. Take it into your next software evaluation. A stack that passes it is one you can keep improving without starting over.

If you’d like an outside read on where your work is coordinated by hand, and what it would take to change that, I’m glad to talk it through. Book a free consultation and we can look at one workflow together.