Build vs Buy: When to Use an App and When to Build It

Build versus buy is the question hiding behind every "there's an app for that" moment: do you install an existing tool, or make your own? The honest default is buy, use the app, for anything that isn't core to how you specifically win, and build only when the thing is genuinely differentiating, when the off-the-shelf option actively fights your process, or when the long-run cost of renting it clearly exceeds the cost of owning it. Most teams get this backwards: they build too much, buy too little, and end up maintaining things they never should have made.

This is a core of the Platforms & Tech Stack cluster, and it's the same judgment that runs through automation, infrastructure, and tooling decisions alike.

The fork in plain terms

Every time a team needs a new capability, a loyalty feature, a reporting dashboard, a way to sync two systems, it hits the same fork. Buy means installing or subscribing to an existing app or tool that does the job. Build means making your own, custom code or an in-house tool shaped exactly to your needs.

The fork looks like a technical question. It's actually a question about cost, ownership, and where your real advantage lives. And the way most teams answer it is biased, because building is more fun and more flattering than buying, and that bias quietly costs them for years.

Why buy is the right default

For the great majority of needs, buying wins, and not by a little. When you buy a tool, someone else maintains it: they fix the bugs, ship the updates, patch the security holes, and keep it working while platforms change underneath. You get the capability now, this week, not in three months when a build might be ready. And the cost is visible and predictable, a subscription line you can see, rather than an open-ended commitment hidden in your team's time.

Most of what a store needs is commodity, the same problem thousands of other stores have. For commodity problems, a mature app already exists, built and refined by a company whose entire focus is that one problem. What you'd build in-house would almost always be more expensive, less capable, and more fragile than the thing you can rent for a modest monthly fee. Reaching for "we'll build it ourselves" on a solved, common problem is usually ego dressed up as strategy.

The hidden cost of building

Here's what sinks most build decisions: the estimate only counts the building. But building something is never "build it once." It's build, then maintain it forever, fix it when it breaks, update it when the things around it change, and keep one person responsible for it being alive at all. That ongoing cost dwarfs the initial build, and it never shows up in the estimate that got the project approved.

Worse, what you build becomes a dependency on the person who built it. When they leave, you're left with a system nobody fully understands and everyone's afraid to touch, the same silent-failure and undocumented-process risk that haunts homemade automation. The true cost of building isn't the build. It's the years of ownership, the maintenance, and the fragility, none of which the exciting kickoff meeting mentions.

When building actually is right

Buying is the default, not a rule. Building is the right call when two or more of these are clearly true:

• The thing is genuinely core to how you specifically win. You don't outsource your competitive edge to an app every competitor can also install. If a capability is the reason customers choose you, owning it can be worth the cost.
• No off-the-shelf option fits, and forcing one would distort your process. Sometimes the available tools would make you change how you work in ways that cost more than building the right thing would.
• The long-run rent clearly exceeds the cost of owning. At real scale, per-seat or per-transaction pricing can grow until buying costs more over time than building and maintaining would. Run that maths honestly, including the maintenance.
• You have the capability to maintain what you build. A build you can't sustain is worse than a tool you rent.

One or two of these in passing isn't enough. The bar for building should be high, because the default, buying, is genuinely good and the cost of building is genuinely hidden.

The middle ground most teams miss

Build-versus-buy is rarely all-or-nothing, and the best answer is often in between. You can buy a capable tool and configure or extend it to fit, rather than building from scratch. Or you can buy the commodity 90% of a need off the shelf and build only the differentiating 10% on top, the part that's actually yours.

Most "we need to build this" conclusions are really "we need to buy the standard thing and customise the bit that matters to us." That gets you the maintained, supported foundation and the piece of genuine differentiation, without owning the whole stack forever. Reach for this middle path before committing to a from-scratch build.

The same judgment as what to automate

If this feels familiar, it should. It's the same discipline as deciding what to automate: don't build a solution to a problem you haven't examined, and don't take ownership of something just because you can. The honest question before any build is twofold, is this thing genuinely core to how we win, and does something already do it well enough? If the answers are "no" and "yes," buy it and move on. The discipline is refusing to build until you've actually asked.

(My own internal-assistant piece is a fair example of where a build can earn its place, something shaped to your own knowledge, where no generic tool fits, and the value is specific to you. That's the bar.)

What this comes down to

The question is almost never "can we build this." You usually can. The real question is "should we own this forever," and for most things the honest answer is no. Buy the commodity, where a maintained, supported tool already solves a common problem better and cheaper than you would. Build the edge, the genuinely differentiating capability that's core to how you win and worth the lifetime of ownership.

And never confuse the fun of building with the cost of maintaining. Most build regret is a thing someone made in an exciting week that the team is now quietly stuck keeping alive for years.

A few common questions

What does "build vs buy" mean? It's the recurring decision behind every new capability you need: buy means installing or subscribing to an existing app or tool that does the job; build means making your own, with custom code or an in-house tool shaped to your needs. It looks like a technical question but it's really about cost, ownership, and where your real advantage lives, and most teams answer it with a bias toward building, which quietly costs them.

When should I buy instead of build? For almost everything that isn't core to how you specifically win, which is most things. When you buy, someone else maintains, fixes, updates, and secures the tool; you get it now rather than in months; and the cost is a visible subscription rather than open-ended team time. Most needs are commodity (the same problem thousands of stores have), and for those a mature app is cheaper, more capable, and more reliable than anything you'd build in-house.

When is building actually the right call? When two or more are clearly true: the thing is genuinely core to how you win (you don't outsource your edge); no off-the-shelf option fits without distorting your process; the long-run rent clearly exceeds the cost of owning at your scale; and you have the capability to maintain what you build. The bar should be high, because buying is genuinely good and the true cost of building, maintaining it forever, not just building it once, is hidden from the estimate.

Isn't it all-or-nothing? No, and the best answer is often in between. You can buy a capable tool and configure or extend it rather than building from scratch, or buy the commodity 90% of a need and build only the differentiating 10% on top. Most "we need to build this" conclusions are really "buy the standard thing and customise the part that's actually ours," which gives you a maintained foundation plus genuine differentiation without owning the whole stack forever.