Build, buy or bridge: choosing how to fix a workflow

The question usually arrives as the wrong question

An owner calls and asks whether they should replace their field service software. The dispatcher hates it. The office retypes much of what comes out of it. The crew uses a small corner of it. A salesperson has already shown them a new platform that does everything.

When we walk the work, the field software is usually fine at what it does. The accounting system is fine at what it does. The problem is the gap between them, where a person reads one screen and types into another every afternoon. Replacing either system moves that gap. It does not close it.

So the real question is not which software to buy. It is where exactly the workflow breaks, and what kind of fix fits that spot. There are three answers: buy, build or bridge. Each is right in some situations and expensive in others.

When to buy

Buy when the work is standard. If many companies do the job the same way, someone has already built a good product for it, and they will maintain it longer and more cheaply than you could. Payroll, general ledger, basic document storage and email are the obvious examples. Nobody wins customers with a custom general ledger.

Buying also fits when the product already matches how your crew works. Not how the vendor says it will work after training. How it works on day one, in the conditions the crew actually faces. The test is simple. Put the product in front of the person who will use it most, in the place they will use it, and watch. If they can do the core task without being coached, it fits. If they need a walkthrough to find the first button, the product is asking them to change, and change is where adoption dies.

The warning sign for buying is the phrase "you can configure it to do that." Configuration is real work, it often needs a specialist, and every upgrade can undo it. A product you have to bend heavily is a custom build you do not own.

When to build

Build when the workflow is part of how you compete. If the way you quote, schedule, inspect or report is a reason customers pick you, a generic product will flatten it into the same process your competitors use. That is a real cost, even if it never shows up on an invoice.

Build also fits when nothing on the market handles your exceptions. Every trade has them. The job that needs two crews on different days. The customer with three sites and one billing contact. The inspection that changes depending on the equipment. If most of your real jobs are exceptions to the product's happy path, the crew will fall back to paper for them, and you will end up in the exception swamp with a new subscription.

The discipline that makes building work is scope. A custom tool scoped to a real problem and a named group of users is a manageable thing to own. A custom platform for the whole company is a second business you did not mean to start. When we build, the scope is set in the Spec: a named group of users and up to two standard integrations, with a handover pack so someone else could run it.

When to bridge

Bridge when each system works on its own and the failure lives between them. This is the case we find most often, and the one owners think about least, because nobody sells it.

A bridge is a small tool that sits between the systems you already run. It takes information in the shape it is captured, whether that is a photo, a form on a phone or a note from a technician, and hands it to the next system in the exact shape that system accepts. Nobody retypes it. Nobody chases it. The crew keeps working the way it already works, and the office stops being the human cable between two screens.

You probably need a bridge if you recognize the re-entry trap: someone whose job includes reading one system and keying into another. Or the field-to-office split, where the field and the office each have a working system and a gap in the middle. Or two systems that show different numbers for the same thing, and a person whose real job is reconciling them.

The bridge has one big advantage over the other two. It asks the least of the crew. They do not learn a new system for everything. They keep the tools they know, and one painful step goes away. That is the kind of change people actually adopt.

A bridge also keeps your options open. If you later replace one of the systems on either side, you replace one end of the bridge, not the whole workflow. And because the bridge is small and does one job, it is easy to see whether it works. Either the retyping stopped or it did not. Either the information arrives on time or it does not. That makes it one of the few kinds of software project where the answer to "did it help?" is plain within a few weeks.

The risk with a bridge is the same as with any custom tool: somebody has to own it. That means the code, the accounts it runs on and the documentation to keep it running belong to you, not to whoever built it.

How to decide, and the option to be wary of

Pick the workflow that hurts most and answer three questions honestly.

First, is the work standard? If you described it to a competitor, would they say "we do it the same way"? If yes, lean toward buying.

Second, is the pain inside a system or between systems? Sit with the person who feels it most and watch where the time goes. If it goes into fighting one screen, the system may be wrong. If it goes into moving information from one screen to another, you need a bridge.

Third, is the workflow part of why customers choose you? If yes, and nothing fits, a focused build may be worth it. If no, do not build just because you can.

Most answers will point somewhere clear. When they do not, that is usually because nobody has watched the work closely enough yet, which is what a Workflow Spec is for. A Spec can end in a recommendation to buy something off the shelf. We would rather say so than build what you did not need.

There is a fourth option owners are often sold: replace everything with one platform. It sounds clean. One login, one database, one vendor.

We have lived through what happens. On the proof page we describe a full replacement system that went live and that the team did not move onto. The software was not the problem. The size of the change was. Every person had to learn a new system for everything at once, for a benefit most of them would never feel personally. What worked afterward were small tools that each fixed one job a specific person did every day.

A full replacement is sometimes right, when every existing system is failing at once. It is rarely the right first move.

What to do next

If the pain sounds like two systems that will not talk, read the guide on accounting and the field app not talking and the one on two systems showing different numbers. Each walks through what you can check yourself before you spend anything.