Build vs buy AI tools for operations: look for the side spreadsheet

Somewhere in most operations there is a spreadsheet that exists because the software could not hold one column. It might track which clients pay in cash, or the renewal date somebody agreed on the phone. The tool bought to run the work had no field for it, so one Tuesday afternoon somebody opened a sheet, and it has been open ever since. Whether to build or buy tends to get decided in sheets like that one, mostly without anyone meaning to decide it.

Why the question got harder

Building software used to cost enough that buying won most of these arguments by default. That changed. Writing the software is now the cheap part, while picking the wrong software costs what it always did, and the bill arrives in the way the team has to work around it, every day, for as long as the choice stands.

Tools with a model inside them add a wrinkle. A bought CRM that drafts replies and tags your clients is making small decisions for you, by rules its makers chose for all of their customers at once. When one of those rules is wrong for your business, the fix is another column in the sheet. Cheap building has its own trap as well, covered further down, which is the urge to build things you should simply pay for.

What bending costs, a day at a time

Bending to a tool rarely looks like a decision. A step the product cannot represent moves into a spreadsheet. After a while it lives in the head of whoever keeps the spreadsheet, and the week that person is on holiday, it drops out of the process.

Give it a couple of years and the operation starts to read like a description of the product's assumptions. A new hire asks why a step exists and is told that this is how the system does it. The people who remember the original reason have long since stopped seeing the workarounds, which makes them hard to price.

A rough price is still possible. Say five people each lose twenty minutes a day keeping the sheet and the tool in step. Over a five day week that comes to eight hours and twenty minutes, a full working day spent maintaining a patch for software you are already paying for.

Those are made up numbers, and yours will differ. The cost model runs the same kind of sum on your real inputs and sets it against a build budget you choose yourself, with no OCTYN price baked into it. Carried over a year or two, that weekly figure belongs in the total cost of ownership of the tool as much as the subscription does.

Building the thing a product already does

The opposite mistake costs more, and a build shop has every reason to leave it out of the pitch. Build your own payroll, accounting, ticketing or calendar and you end up owning a codebase whose entire job is something a product used by far more companies than yours already does better. The edge cases its customers already ran into are now yours to meet one at a time. When the one person who understands the code moves on, you own something nobody can safely change.

The test we use on our compare page is a single question. If a competitor copied this workflow exactly, would it bring them closer to you or leave them further away? Closer means buy. Further away means the workflow is part of why clients pick you, and bending it to fit a product means bending the thing the business is actually good at.

For most teams the answer comes out as both. The bought tools stay where they are, and a small built layer sits in the one place where the work is specific.

What the built part tends to look like

Usually it is narrow. One workflow gets built and wired into the tools you already pay for, rather than replacing any of them, and everything generic stays bought.

Take the outreach engine OCTYN runs for aarttsii, a handmade crochet studio. Its earlier version left geography to the model's judgement, and leads from India and abroad kept landing in the wrong workspace. When the system was rebuilt on 29 July, that call became a plain rule with tests beside it, which removed the failure outright. The change was made by the same people who run the engine. In a bought tool, a call like that sits wherever the vendor put it.

Change looks different as well. On that engine, the description of who to contact is a file of values for each tenant, and a third tenant already runs on the same engine with a completely different idea of who its customers are. Adjusting who gets contacted means editing values, with no product roadmap to wait on.

None of this is free. A built system comes with a deployment, somewhere safe for credentials, a monitor that somebody reads and a codebase somebody can follow, and it needs keeping alive after launch. At OCTYN the people who build a system are the people who run it. The outreach and lead sourcing that run OCTYN's own work were doing that job before either was offered to anyone as a system. When the honest answer to a question is to buy, that is what gets said on the call.

Before anybody builds or buys anything, open the spreadsheet that sits beside your main tool and read its column headers. Between them they list what the tool could not hold.