Why the usual comparison is wrong
The standard build-versus-buy spreadsheet compares license cost to development cost and declares a winner. It almost always favors buying, and it almost always omits the two numbers that actually decide the outcome: configuration effort and workaround cost.The standard build-versus-buy spreadsheet compares license cost to development cost and declares a winner. It almost always favors buying, and it almost always omits the two numbers that actually decide the outcome: configuration effort and workaround cost.
Configuration effort is what it takes to bend a general product to your specific process — fields, automations, permissions, integrations, and the consultant who knows the platform. Workaround cost is what your team pays every day for the gap the product never closes: the export to a spreadsheet, the second system for exceptions, the shared inbox that holds what the tool cannot.Configuration effort is what it takes to bend a general product to your specific process — fields, automations, permissions, integrations, and the consultant who knows the platform. Workaround cost is what your team pays every day for the gap the product never closes: the export to a spreadsheet, the second system for exceptions, the shared inbox that holds what the tool cannot.
Once those are in the comparison, the answer stops being universal and starts being specific to which part of your operation you are talking about.Once those are in the comparison, the answer stops being universal and starts being specific to which part of your operation you are talking about.
Start with differentiation, not features
Sort your systems into three buckets. Commodity: everybody does it roughly the same way — payroll, accounting, email, calendars, payments. Configured: shared shape, meaningful local variation — CRM, project tracking, help desk. Differentiating: the way you do it is part of why customers, members, or volunteers choose you., project tracking, help desk. Differentiating: the way you do it is part of why customers, members, or volunteers choose you.
Buy commodity, always. Buying is not just cheaper here; it is safer, because these categories are heavily regulated, heavily audited, and heavily maintained by vendors whose whole business is keeping them current.Buy commodity, always. Buying is not just cheaper here; it is safer, because these categories are heavily regulated, heavily audited, and heavily maintained by vendors whose whole business is keeping them current.
Configure the middle bucket, and be honest about the ceiling. If you find yourself buying a platform and then paying a specialist for months to make it fit, you have quietly chosen to build — just on someone else's foundation, with someone else's constraints.Configure the middle bucket, and be honest about the ceiling. If you find yourself buying a platform and then paying a specialist for months to make it fit, you have quietly chosen to build — just on someone else's foundation, with someone else's constraints.
Build the differentiating bucket. If your scheduling logic, your approval chain, or your member experience is the thing that makes you good, an off-the-shelf version will make you average at your best feature.Build the differentiating bucket. If your scheduling logic, your approval chain, or your member experience is the thing that makes you good, an off-the-shelf version will make you average at your best feature.
Five questions that resolve most arguments
Does a product exist that fits without heavy configuration? Run a real trial with real data, not a demo. Demos are built on tidy data that never existed in your organization.Does a product exist that fits without heavy configuration? Run a real trial with real data, not a demo. Demos are built on tidy data that never existed in your organization.
Who owns the data, and can you get it out? Ask specifically for export format, API access, and what happens at termination. This question alone eliminates a surprising number of finalists.Who owns the data, and can you get it out? Ask specifically for export format, API access, and what happens at termination. This question alone eliminates a surprising number of finalists.
How many integrations does this need? Each integration is a permanent relationship, not a one-time task. Three well-chosen systems that talk cleanly beat seven best-in-class tools that do not.How many integrations does this need? Each integration is a permanent relationship, not a one-time task. Three well-chosen systems that talk cleanly beat seven best-in-class tools that do not.
What is the exception rate? If ten percent of your cases fall outside what the product handles, you will run a shadow process for that ten percent, and shadow processes are where errors live.What is the exception rate? If ten percent of your cases fall outside what the product handles, you will run a shadow process for that ten percent, and shadow processes are where errors live.
Who maintains it after launch? Both paths create an obligation. Buying means vendor management, renewals, and version changes. Building means hosting, updates, and a development relationship. Neither is maintenance-free, and pretending otherwise is how organizations get stranded.Who maintains it after launch? Both paths create an obligation. Buying means vendor management, renewals, and version changes. Building means hosting, updates, and a development relationship. Neither is maintenance-free, and pretending otherwise is how organizations get stranded.
The hybrid pattern that usually wins
In practice, most healthy stacks are hybrid: bought systems for finance and communication, a configured platform for general record keeping, and one built system that holds the differentiating workflow and connects the rest.In practice, most healthy stacks are hybrid: bought systems for finance and communication, a configured platform for general record keeping, and one built system that holds the differentiating workflow and connects the rest.
The built piece is often smaller than people expect. It may be a portal, an approvals layer, or a data hub that pulls from purchased systems and presents one coherent view. That is a legitimate custom software project, and it is a fraction of the cost of replacing everything. project, and it is a fraction of the cost of replacing everything.
The failure mode to avoid is building a slightly worse copy of a product you could have licensed. If your specification reads like the feature list of an existing tool, buy the tool and spend the budget on the part that is actually yours.The failure mode to avoid is building a slightly worse copy of a product you could have licensed. If your specification reads like the feature list of an existing tool, buy the tool and spend the budget on the part that is actually yours.
Reading total cost honestly
For buying, count license fees over three years, implementation, configuration labor, integration work, per-seat growth, and the cost of the workarounds you already know you will need.For buying, count license fees over three years, implementation, configuration labor, integration work, per-seat growth, and the cost of the workarounds you already know you will need.
For building, count discovery and design, development, hosting, monitoring, support, and the ongoing budget for changes. Then add the cost of a decision you make once and live with: the technology choices that determine who can maintain it later. and design, development, hosting, monitoring, support, and the ongoing budget for changes. Then add the cost of a decision you make once and live with: the technology choices that determine who can maintain it later.
Compare those two totals across the same horizon, and include the value of optionality. A bought system can be replaced. A built system can be extended. Which of those you need depends on whether the process is likely to change and whether the change is yours to make.Compare those two totals across the same horizon, and include the value of optionality. A bought system can be replaced. A built system can be extended. Which of those you need depends on whether the process is likely to change and whether the change is yours to make.
How this conversation usually goes with us
A good portion of our discovery conversations end with us recommending a product the client can buy, plus a much smaller build around it. That is not modesty; it is the cheapest way to a working operation, and it leaves more budget for the parts that only a custom build can solve.A good portion of our discovery conversations end with us recommending a product the client can buy, plus a much smaller build around it. That is not modesty; it is the cheapest way to a working operation, and it leaves more budget for the parts that only a custom build can solve.
When we do recommend building, we say exactly what is being built, what is deliberately left to purchased systems, and what the maintenance obligation looks like in year two. If a partner cannot describe the year-two cost of their own recommendation, that is worth noticing.When we do recommend building, we say exactly what is being built, what is deliberately left to purchased systems, and what the maintenance obligation looks like in year two. If a partner cannot describe the year-two cost of their own recommendation, that is worth noticing.
Questions we get
- Is building always more expensive than buying?
- Not always, and not in the way people expect. Building usually costs more up front and can cost less over several years when the alternative is heavy configuration, per-seat growth, and daily workarounds. The comparison only means something over a three-year horizon.
- What if we already bought a system that does not fit?
- Do not assume replacement. Often the right move is to keep it for what it does well and build a focused layer around the specific gap, connected by integration rather than migration.
- build vs buy
- systems
- procurement
- architecture
