Buy off-the-shelf when a tool fits your process well enough and the subscription is reasonable; build custom when your workflow is your edge, no product fits it, or per-seat fees stop making sense at scale. Most teams should buy for common needs and build only where a custom tool removes real, repeated friction. The deciding questions: does anything off-the-shelf actually fit, and is this workflow core enough to own? Get this call right and you avoid two expensive mistakes at once: building what you could have bought, and bending your business around a tool that never quite fit.
When should you buy off-the-shelf?
When a proven product covers your need at a fair price. For common functions — email, accounting, CRM, support — off-the-shelf software is cheaper, faster, and maintained for you. Buying wins when your process isn't unusual and an existing tool fits without contortion. Building something a $30-a-month tool already does well is rarely worth it. Most internal needs are common needs, so buy is the right default more often than founders think. The honest rule: if a tool does 80% of what you need and the missing 20% isn't core, buy it and adapt — your time is better spent on the work that actually differentiates you.
When does building pay off?
When the workflow is specific to how you work and no product fits without forcing your process to bend around it — or when per-seat pricing balloons as you grow. A custom internal tool pays off when it removes repeated friction, encodes a process that's genuinely your advantage, or replaces a stack of subscriptions that no longer adds up. If you're hacking spreadsheets and three tools together to limp through a core process, that's the signal. The clearest case for building is when the workflow itself is your advantage — the way you do this thing is part of why customers choose you, and no generic tool can express it.
What's the real cost of each?
Buying costs recurring fees forever and means living within the product's limits and roadmap. Building costs more up front and needs maintenance, but you own it, it fits exactly, and there's no per-seat meter. The honest comparison isn't sticker price — it's total cost and fit over a few years, plus how core the workflow is. For a throwaway need, buy. For a process you'll run for years, owning it often wins out. Don't forget the hidden costs on both sides: bought tools accrete — five subscriptions that each made sense become a tax nobody reviews — while built tools need an owner to maintain them. The right comparison is total cost of ownership over three years, not only the monthly sticker.
What about no-code and low-code tools?
They're a real third option that sits between buy and build. No-code and low-code platforms let you assemble a custom-ish internal tool fast, without a full development project — great for validating a workflow or covering a need that's specific but not performance-critical. The limits show up at scale and at the edges: you hit something the platform won't do, pricing climbs with usage, and you're building on someone else's system you don't fully own. My rule mirrors the SaaS one: use no-code to validate or for genuinely simple internal needs, and build custom when the tool is core, must integrate deeply, or has outgrown what a platform allows.
How do you avoid buying a stack you can't manage?
Audit before you add. The quiet failure mode of "just buy it" is subscription sprawl — a dozen tools that each solved one thing, now overlapping, half-used, and collectively expensive. Before adding another tool, ask whether something you already pay for can do the job, and once a year, cut what no one uses. The goal isn't to minimize tools for its own sake; it's to keep the stack to things that earn their keep and play well together. A lean, intentional set of tools beats a graveyard of trials, the same way a focused custom build beats an over-scoped one.
How do I help decide?
I look at fit and how core the workflow is. If something off-the-shelf fits, I'll say buy it — no upsell. If your process is your edge or subscriptions have stopped scaling, a focused custom tool pays off, the model behind my web-apps service. It's often the same move as graduating off spreadsheets, which I cover in signs you've outgrown spreadsheets. Build only what earns it.
Related web app guides
See signs you've outgrown spreadsheets, website vs web app, and how much a web app costs.
Weighing build vs buy? Tell me what you're building — I'll give you the honest call, even if it's "just buy it."
