Build vs buy: price the maintenance before you price the build

By Meet Patel · 2026-10-03 · 6 min read

The usual build-versus-buy discussion compares two numbers: the engineering estimate to build and the vendor’s annual price. Those are the two smallest numbers in the decision. Levi Strauss’s SAP implementation began with a proposed budget of under $5 million and ended in a $192.5 million charge against earnings (Flyvbjerg and Budzier, Harvard Business Review, 2011). The case involved a bought platform rather than a built one, and it shows the same pattern from the other side: the up-front figure was a fraction of what the choice cost.

The costs that decide the question arrive after the decision is made. They include the overrun on the build, the years of maintenance, the dependence on whoever understands the code, the work the same engineers did not do elsewhere, and the price of leaving. A scorecard that prices all of them takes about an hour to build and can change the answer.

The build estimate is the optimistic number

Flyvbjerg and Budzier studied 1,471 IT projects and found an average cost overrun of 27 percent. The average understates the risk: about one in six projects in the sample overran its budget by 200 percent on average and slipped its schedule by almost 70 percent (Flyvbjerg and Budzier, 2011). A single build estimate from a team that wants to build is an inside-view forecast, in the language of the sibling post on reference class forecasting, and the honest correction is to widen it with the record of similar projects.

A practical rule is to enter the build cost at the estimate multiplied by 1.27 as the central case, and to run a second case at three times the estimate, which is what a 200 percent overrun means, to see whether the decision survives it. If the build only wins in the optimistic case, it has not won.

Maintenance is most of the lifetime cost

Robert Glass, in Facts and Fallacies of Software Engineering, lists maintenance as typically consuming 40 to 80 percent of software costs (review of Glass’s list). He also records that understanding the existing product consumes roughly 30 percent of maintenance time and is the dominant maintenance activity. That second point matters for small companies, because the person who understands a homegrown tool is usually the person who built it, and the tool’s cost climbs when that person moves on.

A formula turns the Glass range into a lifetime view. If maintenance takes a share m of lifetime cost, then lifetime cost equals build cost divided by (1 minus m). For a $100,000 build, a maintenance share of 40 percent gives a lifetime cost of about $167,000, 60 percent gives $250,000, and 80 percent gives $500,000. Treat this as a rule of thumb from one author’s compilation and as a way to see the scale, since your own tool will land somewhere inside or outside the range.

Stripe’s Developer Coefficient report, built on a Harris Poll survey of more than 1,000 developers and more than 1,000 C-level executives in five countries, points the same way. Developer respondents estimated that 17.3 hours of a 41.1-hour week went to maintenance, meaning bad code, errors, debugging, refactoring and modifying (Stripe, The Developer Coefficient, September 2018). That is about 42 percent of the week. Respondents gave estimates, the report includes no timesheet data, and the direction is consistent with Glass.

A worked example, with invented numbers

Take a hypothetical 40-person company that wants an internal tool to manage customer onboarding. Every figure below is an illustration. Assume an engineer costs $12,500 a month fully loaded (salary, benefits, equipment and overhead).

• Build estimate: 2 engineers for 3 months is $75,000.
• Build, adjusted: times 1.27 is $95,250. The stress case at 3 times is $225,000.
• Maintenance: half an engineer’s time afterwards is $75,000 a year, or $225,000 over three years.
• Three-year cost to build: $95,250 plus $225,000 is $320,250. Maintenance is 70 percent of that total, which sits inside the Glass range.
• Three-year cost to buy: a $2,000 monthly subscription is $72,000, plus one tenth of an engineer for integration and administration at $15,000 a year, or $45,000. Total: $117,000.

The gap is $203,250 over three years, and the build also uses 6 engineer-months of capacity up front. If those engineers would otherwise ship a feature customers pay for, the opportunity cost sits on top of the figures above. The company can still choose to build, and now it knows the price of that choice.

The buy column has hidden costs of its own: implementation time, data migration, the administrator who configures the tool, seats that grow with headcount, and renewal pricing. The example includes one tenth of an engineer for integration and administration. On a real quote, ask the vendor for the three-year price at your projected headcount and ask what caps the renewal increase. The Levi Strauss case is a reminder that a bought system can overrun too.

A scorecard with weights

Cost figures answer half the question. A scorecard adds the rest and forces the weights to be stated before anyone argues for an option. Score each option from 1 to 5, where 5 is best for that option, and multiply by the weight.

• Differentiation, weight 30%: does this capability decide whether customers choose us?
• Three-year cost, weight 25%: including overrun and maintenance.
• Time to value, weight 15%: how soon does it work for real users?
• Ownership capacity, weight 20%: is there a named person with time to maintain it?
• Exit and lock-in, weight 10%: what does it cost to leave?

For the onboarding tool, a plausible scoring is: differentiation 2 for build and 4 for buy, because onboarding is a support process and customers do not pick the company for it; cost 2 and 4; time to value 2 and 5; ownership 2 and 4; exit 4 and 3. The weighted totals are 2.2 for build and 4.05 for buy.

The useful step comes next, which is to change one assumption. Suppose the capability is core, so differentiation scores 5 for build and 2 for buy. The totals become 3.1 and 3.45, nearly a tie, and the decision now rests on the ownership score. That is the pattern I would expect in general: a core capability earns the right to be built, and the build still has to find an owner.

When building wins

Four conditions favor a build, and each one maps to a line in the scorecard.

1. The capability is part of what customers choose you for, so the differentiation weight should be high and honest.
2. No vendor meets a hard constraint, such as data residency or response time. Treat this as a pass or fail test that ends the comparison before scoring begins.
3. The vendor’s price grows with your volume faster than the maintenance on a built tool would, which shows up in the three-year cost at your projected usage.
4. A named person has the time and the skills to own it, which is the ownership line.

When all four hold, build, and fund the maintenance as a permanent line in the plan. When fewer than three hold, the burden of proof sits with the build.

Rules that follow from the numbers

1. Name the maintainer before the first commit. If nobody can be named with time allocated, the build cost in your model is missing a row.
2. Build what customers pay you for, and buy what supports it. The scorecard’s differentiation weight encodes that, and it is the criterion most likely to be argued down by people who enjoy building.
3. Price the exit. For a bought tool, confirm you can export your data in a usable format. For a built tool, write down what it would take to replace it.
4. Set a review date. Revisit the decision at 12 months with real maintenance hours, since the model’s assumptions will have been tested by then. An internal tool left running without review is the same pattern as 41 dashboards with 19 unopened for a month: things get built, and then nobody checks whether they are still used.
5. Constrain the build. A narrow first version limits the overrun and the maintenance surface, which fits the argument in constraint is strategy.

A build estimate is a forecast of the cheapest part of owning software. Any decision that stops there compares the price of making something with the price of renting something, and leaves out the cost of keeping either, which is where software spends most of its life. The principle I would apply is to compare what each option costs to own for three years, name who owns it, and decide only after both numbers exist.

Written by Meet Patel — startup operator and growth strategist in Dubai.

Read on themeetpatel.com