Buying or Building Misses the Real Question

Every few months I sit in a version of the same meeting. Someone has a spreadsheet with two columns. One column is the annual cost of a platform. The other is an estimate to build something custom. The room treats the smaller number as the answer.

That spreadsheet is not a decision. It is a price tag with a costume on.

The cost of the software, bought or built, is the easy part to put in a cell. The hard part is what happens the first time the workflow has to change — which it will, because the business will. A new service line shows up. A carrier starts requiring appointments the dock cannot produce from a whiteboard. A bid needs a compliance section nobody planned for. A campaign that used to end at "lead created" now has to carry context into delivery, or the lead goes cold in the gap. Whoever is allowed to change the system in that moment owns the decision you thought you made when you signed the contract or approved the scope.

The comparison that feels rigorous

Buy-or-build feels like a serious operator question because it has numbers on it. Licenses. Implementation. Hours. Hosting. You can argue about the figures, get a second quote, and leave the meeting feeling like you did diligence.

What the comparison hides is the shape of the work after the decision. If you buy, the workflow lives on someone else's roadmap. Configuration is real power, right up until the thing you need is not a setting. Then you wait, you workaround, or you pay for a customization that belongs cleanly to neither you nor the product. If you build, the workflow is yours — and so is every bug, every security update, and every new hire who has to learn a system that exists nowhere else.

I have watched both failure modes from Ponte Vedra — in our own companies and in the operational systems we put in place for other businesses. The bought system that was "close enough" until the exception became the job. The custom system that matched the business on delivery day and drifted every month after, because nobody was named to keep it matched.

Neither of those is a software failure. Both are ownership failures.

Common work wants a product. Specific work wants an owner.

The useful split is not whether custom costs more this year. It is whether the workflow is common enough that someone should be improving it as their job, or specific enough that a general product will always be a compromise your team routes around.

A lot of what sounds unique in a discovery conversation is a common operating loop with local nouns. A client comes in, work gets assigned, someone does it, someone else needs to know it is done, and the invoice has to follow without a person remembering to start it. We stopped rebuilding that loop as a one-off and put it in IFX Hub. A product can hold the changes that keep showing up — task history, an approval next to the work, a closed deal that becomes delivery without a retype — without depending on whoever built the last version.

Growth gets mislabeled the same way. Companies buy campaigns and a pile of tools, then discover nothing remembers what happened to a lead after the send. Growth7 is the product we built for the part we kept repeating: the next action, the scoring, and the context have to survive past the campaign. A retainer buys activity. A system holds the record of what the activity did. Those are different purchases.

Procurement response is common in a narrower way. Teams still assemble it in spreadsheets and shared drives because a lot of procurement software was built for the office that buys, not for the people writing the response. IFX Bid treats the response as the record: who owns the opportunity, who owns each section, and what "ready to submit" means when the due date is close. Another column on a generic tracker does not do that.

Dock scheduling is the case for a product aimed at one job. The appointment at the door is a promise to a carrier and a plan for the people inside. The person at the door needs that schedule in front of them when a truck is early and a door is full. DockOps exists because that change has to happen at the speed of the yard, not inside a platform that "also does scheduling."

Some workflows should stay custom. A pricing exception, a handoff between crews, an approval path that would be nonsense next door — that is often the edge, and forcing it into a product means the workaround becomes the real system. Building it once, on the business system you already run, is the right call if someone who still works there can change it when the edge moves. At Infraxio the scoping question I care about is not whether we can make the screens. It is who calls — us, or someone on the client's own team — the month the process changes.

I have written about when a custom build is the wrong project. This is the step after that call goes the other way. A justified build still fails if the only person who can change it is the person who delivered it and left.

What each choice actually commits you to

When you buy a platform, you are accepting that your important changes are the same changes other customers will demand, and that those changes will show up before a workaround hardens into how the company operates. That is a sound deal for a lot of the boring middle: accounting close, payroll, the standard order path. It is a poor deal for the workflow that makes the business different, and a poor deal for any workflow the team has already walked away from more than once.

When you build, you are buying the right to change the workflow without filing a request. You are also buying the obligation to keep changing it. A custom system with no owner is a more expensive spreadsheet. It is right on launch day. After that it drifts, quietly, until someone trusts a status or a handoff that no longer means what the screen says.

If you already have a system, replace or fix is the prior question, and it is a different one. Buy-or-build is what people reach for when they are tired of what they have. Both questions skip the same step if you never name who can change the workflow next.

Do this before you price anything

Before you put a license next to a build estimate, write down three workflows that will have to change in the next year. Not a feature list. Workflows: who does the work, what they hand to the next person, and what "done" means.

Next to each one, write a name. Not a department. A person who is allowed to change how that workflow runs — in the product, in the configuration, or in the custom system — without standing up a new project from zero.

If you cannot write the name, you are not ready to buy and you are not ready to build. You are about to design a dependency and call it a system.

If the name is a vendor's success manager, say plainly that you are waiting on their roadmap, and only buy if that wait is acceptable for this workflow. If the name is someone on your team, pick the system that lets them change the workflow as part of the job, not as a favor after hours. If the name is a consultant who will leave, write down who they hand it to. A build without that handoff is a rental you paid for as if you owned it.

The smaller number on the spreadsheet is not the decision. The name next to the workflow is.