Buy vs. Build Is the Wrong Ticket. Ask Who Can Change the Workflow.

Originally published on penningtonj.com.

If you have shipped internal tools for long enough, you have seen this ticket: "Evaluate buy vs. build for X." Somebody attaches a spreadsheet. One column is a SaaS license. The other is an engineering estimate. Whichever number is smaller wins, and the team moves on.

I run a small product studio in Ponte Vedra, Florida, and I have watched that spreadsheet make the wrong call in both directions. The problem is not the math. The problem is that the spreadsheet measures the cheapest thing to estimate and skips the thing that actually decides whether the project works.

The variable nobody puts in a cell

The question that matters is this: when the workflow changes next quarter, who is allowed to change the system?

It will change. A new service line appears. A customer starts requiring something the current process can't produce. A compliance section shows up in a bid that nobody planned for. A handoff that used to end at "lead created" now has to carry context all the way into delivery.

Whoever can make that change, quickly and without opening a new project, owns the system. Not whoever paid for it.

Two failure modes, same root cause

Bought, and "close enough." Configuration feels like power right up until the thing you need is not a setting. Then you file a feature request, build a workaround, or pay for a customization that belongs cleanly to neither you nor the vendor. Six months later the workaround is the real system and the product is the thing people log into for reporting.

Built, and orphaned. The custom tool matched the business perfectly on launch day. Then the person who built it moved on, nobody was named to keep it matched, and it drifted every month after. Eventually someone trusts a status field that no longer means what the screen says.

Neither one is a software failure. Both are ownership failures.

A better split: common loops vs. specific edges

Instead of "which is cheaper this year," ask whether the workflow is common enough that someone should be improving it as their full-time job, or specific enough that any general product will always be a compromise your team routes around.

A surprising amount of what sounds unique in discovery is a common loop with local nouns:

1. Work comes in.
2. It gets assigned.
3. Someone does it.
4. Someone else needs to know it's done.
5. The invoice follows without a human remembering to start it.

That loop wants a product. We stopped rebuilding it as one-off client code at Infraxio and put it into IFX Hub, so task history, approvals next to the work, and closed-deal-to-delivery all live in a system that does not depend on whoever wrote the last version.

The same logic applies to narrower jobs. Dock scheduling is a good example: the appointment at the door is a promise to a carrier and a plan for the crew inside, and it has to change at the speed of the yard. That is why DockOps is aimed at one job instead of being a tab inside a platform that "also does scheduling."

Then there are the true edges: a pricing exception, a crew-to-crew handoff, an approval path that would make no sense at the company next door. Forcing those into a generic product usually means the workaround becomes the system. Those are worth building, on the stack you already run, if someone who still works there can change them when the edge moves.

What each choice really commits you to

Buying is a great deal for the boring middle: accounting close, payroll, the standard order path. It is a bad deal for the workflow that makes you different, or one your team has already abandoned twice.

Building without an owner just gets you a more expensive spreadsheet.

Do this before anyone prices anything

Before the license-vs-estimate spreadsheet exists, write down three workflows that will have to change in the next twelve months. Not features. Workflows: who does the work, what they hand off, and what "done" means.

Next to each one, write a name. Not a team. A person who can change how that workflow runs (in the product, the config, or the codebase) without kicking off a new project.

• If you can't write a name, you're not ready to buy or build. You're about to design a dependency and call it a system.
• If the name is a vendor's customer success manager, be honest that you're waiting on their roadmap, and only buy if that wait is acceptable for this workflow.
• If the name is someone on your team, choose whatever lets them change it as part of the job, not as an after-hours favor.
• If the name is a contractor who will leave, write down who they hand it to. A build without that handoff is a rental you paid for like you owned it.

The smaller number on the spreadsheet isn't the decision. The name next to the workflow is.

I'm Justin Pennington, founder of Infraxio, a product studio in Ponte Vedra building operational software for businesses across Northeast Florida and beyond. More essays at penningtonj.com.