When To Build Custom Software Instead Of Buying Off The Shelf

A founder shows us a spreadsheet that has quietly become the spine of the business. It tracks orders, computes commissions, and gets emailed around in versions like final_v3_REAL.xlsx. Three people maintain it by hand, one of them is leaving, and it breaks in a new way every month. The question on the table is whether to build a custom tool for it or pay for an off-the-shelf one. It is the right question, and most founders answer it backwards.

The backwards answer is "build, because our business is special." Almost every business feels special, and almost every business runs on workflows that are not special at all. The cost of building custom software for a problem a subscription already solves is one of the most expensive mistakes a young company can make, because it spends your scarcest resource, engineering time, on something that creates no advantage. But the opposite mistake, forcing a generic tool to do the one thing that actually makes you money, is just as costly in the other direction. The skill is telling the two apart, and there is a clean rule for it.

Core versus context: the rule that decides most cases

The most useful framing comes from a simple distinction, and it carries over to the AI version of the same question: deciding what AI to build and what to buy. Split everything your business does into two buckets.

Core is your differentiator. It is the proprietary functionality customers pay you for, the reason you exist rather than a competitor. It is the thing you could not buy even if you wanted to, because if you could, your competitors would buy it too and you would have no edge.

Context is everything else required to run the business. It is mission-critical, you cannot operate without it, but it does not differentiate you. Payroll, email, accounting, basic CRM, file storage, the company wiki. Necessary, and identical to what every other company needs.

The golden rule follows directly: invest your engineering talent in Core, and buy SaaS for Context. Building custom payroll software is almost never right, because payroll does not win you customers and a dozen mature products already do it better than you will. Building the custom logic that makes your product unique is almost always right, because that is the thing no subscription will ever sell you. Most buy-versus-build questions answer themselves the moment you sort the workflow into the right bucket.

The spreadsheet from the opening? It depends entirely on which bucket the workflow lives in. If it is generic order tracking, a SaaS tool replaces it in days. If it encodes a commission structure and an operating model that is genuinely particular to how this business wins, it might be Core, and Core is worth building. The only way to know which workflows are genuinely Core is usually to have been in the room selling, which is one more reason founders should sell the first hundred deals themselves before they commit engineering time.

The questions that sharpen the call

Core versus context settles the obvious cases. For the genuinely close ones, run four more checks.

How fast do you need it?

If you need something working in the next four to six weeks, custom development is almost certainly not the answer, unless you have scoped an MVP that ships in six weeks by cutting the build down to only the core that matters. A SaaS tool stands up in days. Custom software is measured in months. When the need is urgent and the workflow is generic, buy now and revisit later. Time-to-value is a real cost, and a business bleeding from a broken process cannot wait a quarter for a perfect tool.

What is the true cost over three to five years?

The trap in the cost comparison is looking only at the sticker price. A SaaS subscription that looks cheap at 50 dollars a seat per month is not cheap at 40 seats over five years, especially once the per-seat price climbs as you grow. Custom software that looks expensive up front carries no per-seat tax but does carry maintenance, hosting, and the engineering time to keep it alive, the same hidden line items that surface when you compare self-hosting versus managed cloud on true cost. Compare total cost of ownership over a realistic horizon, including implementation, customization, support, and the opportunity cost of the engineers who build it instead of building product. Whatever you settle on still has to fit a software budget that survives your runway. Sometimes the subscription wins, sometimes the custom build does, but only the full-horizon number tells you which.

Does the off-the-shelf tool actually fit, or will you bend your business to it?

A SaaS tool encodes its makers' assumptions about how the work should be done. If those assumptions match yours, wonderful. If they do not, you face a worse choice than building: you bend your business to fit the tool, or you pay for endless customization and integration work that often costs more than a custom build would have. The question is not "does a product exist for this," it is "does a product exist that fits the way we actually operate." When the answer is no and the workflow matters, the apparent savings of buying evaporate.

Will you have to stitch several tools together anyway?

Often the real situation is that no single product covers the workflow, so you would buy three tools and spend months wiring them together with brittle integrations. At that point the integration work approaches the cost of building the thing properly, and a custom tool that does the whole job cleanly can be both cheaper and more reliable than a Frankenstein of subscriptions held together with tape.

The pattern we see in practice

Working with startups, the highest-leverage custom builds are almost always the same shape: the one or two workflows that are genuinely particular to how the business operates and creates value, the ones where the founder lights up explaining why their version is different. Those are Core, and a custom web application built around them gives the business something no competitor can subscribe to. The same Core-versus-Context logic decides whether you build with your first software hire being an engineer or an agency and whether you keep that work in house or outsource it for the velocity you need: you want your scarce builders pointed at the differentiator.

The lowest-leverage builds are the ones where a founder wanted control or felt the subscription was overpriced, and built a worse version of a solved problem. The custom CRM that does less than the 30-dollar one. The internal chat tool. The homegrown analytics. Every hour spent on those is an hour not spent on the thing customers actually pay for.

The honest pattern is a hybrid. Buy SaaS for all the context, ruthlessly, so your team never builds payroll or email or basic accounting. Build custom for the narrow core that differentiates you, and build it well, because that is where engineering time turns into competitive advantage rather than reinvented commodity. When founders bring us a build-versus-buy question, the consultation usually spends most of its time on one thing: sorting the workflow into Core or Context, because once it is sorted, the decision is rarely close.

The short version

You have a fixed amount of engineering capacity, and the buy-versus-build decision is really a decision about where to spend it. Spend it on Core, the workflows that make you money and that no subscription will sell you. Buy Context, the necessary-but-undifferentiated machinery every company needs, and never let pride or a slightly-too-high subscription price talk you into rebuilding a solved problem.

When you are unsure, ask which bucket the workflow is in, how fast you need it, what it truly costs over five years, and whether the off-the-shelf option fits or fights your business. Those questions resolve almost every case. The rare ones that stay close are worth talking through with someone who has watched both decisions play out, because the cost of building the wrong thing, or buying the wrong thing, is paid in the one resource a startup can never get back.