Build, buy, improve, integrate, or leave it alone

Operational friction has at least five possible fixes, not two. Most people jump straight to “build something” or “buy something,” as if those are the only options. Picking the wrong one is a common way to overspend on a problem that needed a much smaller fix.

The five options

Build.Create custom software or a custom AI workflow designed around your exact process. This makes sense when your workflow is unusual, when off-the-shelf tools don't fit, or when the process is central enough to your advantage that it's worth owning outright.

Buy. Purchase an existing tool built for this exact problem. This makes sense when the problem is common: payroll, scheduling, invoicing, basic support. Someone else has already built and refined a solution better than you could justify building yourself.

Improve. Use more of what you already own. Most businesses run software at a fraction of its real capability. The cheapest fix is often turning on a feature nobody configured, not adding a new subscription.

Integrate. Connect two systems you already have so information stops being retyped between them. This makes sense when the friction is about disconnected tools, not missing capability.

Leave it alone. Some friction costs less than the fix. If a task takes ten minutes a month, spending real money and attention solving it is a bad trade, no matter how annoying it feels in the moment.

Seeing the choice in practice

At a regional gas station chain, store managers spend hours each week compiling fuel and merchandise sales into a single report for headquarters. The point-of-sale system and the accounting software both already track this data. Neither one talks to the other. That points to an integration fix, not a build. A connector between the two systems removes almost all of the manual compilation, for far less than a custom reporting tool would cost.

A specialty manufacturer already owned what it needed and didn't know it. The project management software it ran every day included automated status reporting, approval routing, and client-facing dashboards, and nobody had ever turned them on. That makes it an improve decision: the fix is training and configuration, not a purchase.

Then there is the logistics company whose multi-step approval process, shaped by years of regulatory requirements, is unusual enough that no off-the-shelf product fits without heavy compromise. Building is the right call here: the process is specific enough, and important enough, to justify custom software.

A framework for making the call

1. Does a mature tool already exist for this exact problem? If yes, lean toward buy.
2. Do you already own software with unused capability that could cover this? If yes, lean toward improve.
3. Is the pain about two systems not talking to each other? If yes, lean toward integrate.
4. Is your process specific enough that no existing tool fits without major compromise, and is it valuable enough to justify ownership? If yes, consider build.
5. Does the cost of the friction, counted in hours and dollars, fall below the cost of any fix? If yes, leave it alone.

Questions to ask before committing

• What would I choose if a vendor weren't in the room?
• Have I checked what my current tools can already do before adding a new one?
• Is this friction big enough, in hours or dollars, to justify the time and money any of these paths would cost?

Bottom line

Build and buy get all the attention, but they're only two of five reasonable paths. Improving what you already have, integrating systems that don't talk to each other, or leaving a small annoyance alone are often the smarter, cheaper moves. The right choice depends entirely on the specific friction, which is why diagnosing it well matters more than knowing which tools exist.