Build vs Buy vs Integrate: How We Actually Decide (With 3 Real Projects)

"Build vs buy" is missing a third option—and it's usually the right one.

Most software decisions get framed as a fork: build it custom, or buy it off the shelf. Framed that way, you'll usually pick wrong. Build everything and you burn money reinventing commodities. Buy everything and you cap your business at whatever generic tools allow.

The option that quietly wins most of the time is the one that's missing from the question: integrate. Buy the commodity pieces, build the thin layer that's uniquely yours, and connect them into one system. Most well-run companies aren't all-custom or all-SaaS. They're a deliberate mix, assembled around a clear decision map.

Here's the map we use—and three project types that show how the same map produces three different answers.

The decision map

Before build, buy, or integrate, we ask three questions in order.

1. Is this a commodity or your edge?

Commodities are solved problems every company does the same way—accounting, email, scheduling, payments. Your edge is the workflow, logic, or data model that makes your business distinctive. Commodities lean toward buy. Edges lean toward build. This one question resolves more decisions than any other.

2. Does a good tool already fit your real process—or only if you bend the process to it?

If an off-the-shelf tool matches how you actually work, buying it is a gift. If using it means changing how you operate, count that as a cost, not a convenience. Bending your business to fit a tool is how you lose your edge one setting at a time.

3. What does this decision cost at 3x scale?

The cheap option today can be the expensive option at volume. A manual workaround that takes ten minutes a day is fine now and unbearable at ten times the load. Decide for where you're going, not where you are.

Run those three questions and one of three shapes emerges. Let's walk each through a real project type.

Build: when the software is the business

Some projects aren't about supporting the business—the software is the product, or the core operating system the whole business runs on. Here, off-the-shelf isn't a shortcut; it's a ceiling you'd hit immediately.

Proptely is a clear example of build, delivered by FIFTH as client work. Property operations carry logic that consumer and generic tools simply don't share: how units, tenants, leases, maintenance, documents, and payments relate to each other; what a portfolio-level view actually needs to surface; how a single status change should cascade through everything downstream. That logic is the value. You can't buy it, because no vendor built their data model around your market's specific shape.

Run the map: the core workflow is the edge, not a commodity. No off-the-shelf tool fits without forcing the business to contort around it. And at scale, the workarounds compound rather than resolve. All three questions point the same direction—build.

But notice what "build" doesn't mean here. It doesn't mean building everything. Even a custom platform buys its commodity layers—hosting, authentication, payment processing, email delivery. You build the edge and buy the plumbing underneath it. Building well is as much about knowing what not to build as what to build.

Buy: when someone already solved it better than you could

The opposite shape shows up constantly, and disciplined teams say "buy" without ego. If a function is a commodity—something thousands of companies do identically—building it custom is almost always a waste of money and focus. The market has already produced mature tools, refined over years, that you'll never beat by starting from scratch.

Picture a growing services business setting up its finance and operations stack. Accounting, payroll, e-signatures, calendar scheduling, basic file storage—every one of these is a solved problem. The right move is to buy the best-fit tools and spend zero engineering effort there. Every hour spent building a custom invoicing system is an hour not spent on the thing that actually differentiates the business.

Run the map: these are commodities, not edges. Good tools fit the process without forcing change. And at scale, mature SaaS handles the load better than a home-grown version would. Buy, cleanly, and move on.

The discipline here is resisting the temptation to build for its own sake. Engineering teams like building. The strategic move is often to not build—to reserve custom effort for the places it creates a real advantage, and buy everywhere else.

Integrate: when the pieces exist but the system doesn't

This is the shape most businesses actually need, and the one they most often miss. The individual tools are fine. The problem is that they don't work as a system—data lives in silos, work gets re-entered by hand, and the connective tissue between tools is a pile of manual exports and fragile automations nobody designed.

Integrate means: keep the good commodity tools, build the thin custom layer that's genuinely yours, and connect everything into one coherent flow.

ZYR, a content and marketing automation platform FIFTH built as client work, reflects this shape. Marketing operations sprawl across many specialized tools—each good at its job, none aware of the others. The value isn't in rebuilding any one of them; it's in the layer that orchestrates them into a single automated workflow, so content and campaigns move through the system without a person manually carrying data between tools. You keep what's already good and build the intelligence that connects it.

Run the map: some pieces are commodities worth keeping (buy), but the orchestration logic is the edge (build), and the current cost is entirely in the manual seams between tools—cost that explodes at scale. The answer isn't build-from-scratch or buy-one-more-tool. It's integrate: a designed layer that turns a pile of tools into a system.

Integration is the least glamorous of the three and often the highest-leverage. It respects the money already spent on tools that work, and puts new effort exactly where the friction is—the gaps between them.

Why the map beats a preference

The reason we run the map instead of leading with a recommendation is simple: the same business needs all three answers at once. It should build its core platform, buy its commodity stack, and integrate the two into one system. A partner who only sells custom builds will tell you to build everything. A SaaS reseller will tell you to buy everything. Both are optimizing for their business, not yours.

The map is neutral. It doesn't care what we'd prefer to sell. It asks what the decision actually is—commodity or edge, fits or forces, cheap now or cheap at scale—and lets the answer fall out. Sometimes that means a platform. Sometimes it means "you don't need us to build this, buy it." Most often it means a hybrid designed on purpose.

Our perspective

This is what being an embedded partner actually means. We're not walking in to sell you the biggest build. We're walking in to design the system—which means being honest about what to build, what to buy, and what to connect. Sometimes the highest-value thing we do is talk a client out of a custom project they didn't need.

Your business doesn't need more tools, and it doesn't need everything rebuilt from scratch. It needs a system where the right things are built, the right things are bought, and the whole thing works as one. That's the decision the map is designed to get right.

Where to start

Take your three most important software decisions right now and run each through the three questions: commodity or edge, fits or forces, cheap now or cheap at scale. You'll likely find one clear build, one clear buy, and one that's really an integration problem in disguise.

If you want that map drawn against your actual business, that's exactly the conversation we have with clients before anything gets built. We'd be glad to have it with you.