Naive
The build estimate alone. No maintenance line at all, so this is the number a first comparison reaches for.
FREE TEMPLATE
Build vs Buy Technical Decision Template
Two documents and three sheets, including a total cost of ownership that prices the build option's maintenance by task instead of a flat percentage.
Free download · No account needed
Total Cost over Three Years, the build side
Three ways to price the same maintenance, and only one is checked against a task
Filled in once the build estimate and the vendor's price both exist. The subscription total is a real figure from a pricing page. The build side's upkeep is usually not.
Heuristic
A flat percentage of the build cost, commonly 15 to 20 percent a year, applied without asking what it is actually paying for.
Real, priced by task
Bugs and dependency upgrades, on-call, feature requests, security and compliance. Each one is its own fraction of an engineer's time, with its own growth curve as adoption spreads.
Buy Side
Subscription with its stated escalation, implementation, and an integration-maintenance fraction for keeping the vendor's SDK current.
Page one for this query is templates and calculators that all run the same shape: a three-year total cost of ownership, a build estimate against a subscription total, with maintenance folded in as a line item. IdeaPlan's own build-vs-buy template names the gap correctly: "the initial build is 20-30% of the lifetime cost," with maintenance, upgrades, security patches, scaling and on-call burden accumulating for years. It leaves every one of those five categories unquantified. Naming the risk is not pricing it.
This pack prices the build option's maintenance the way an engineering manager actually staffs it: as separate tasks, each carrying its own fraction of an engineer's time, rather than one flat percentage of the build cost. Bug fixes and dependency upgrades get a task, on-call gets a task, and feature requests from the teams now depending on the tool get a task of their own, the one that typically grows fastest as adoption spreads internally. Security and compliance work is priced separately too, instead of hiding inside a single "maintenance" line.
At Cordata Systems, a fictional B2B software company, building an in-house feature flag platform costs $132,000 up front against Flagcastle's three-year subscription of $245,600, which is the naive comparison that makes building look $113,600 cheaper. A flat 20-percent-of-build heuristic narrows that to $41,600 in build's favor. Priced by task, Cordata's own maintenance load grows from 0.28 to 0.46 of an engineer over three years, mostly from feature requests, pushing the real build total to $333,600. Buying is actually $88,000 cheaper, next to the technical program plan tracking the programme this decision feeds.
What's in the pack
01
Capability Comparison
Every feature the buy side ships, marked native, partial or absent for the build option, so the decision starts from named gaps rather than a general sense of parity.
02
Total Cost over Three Years
The naive build figure, the flat-heuristic figure, and the task-priced real figure next to the buy figure's own escalation and integration cost, so a reversal between them is visible.
03
Switching Cost Estimate
What it costs to leave each option, not just adopt it, priced in both directions because decommissioning a build is frequently harder than exporting data from a vendor.
04
Decision Analysis
The differentiating capabilities, the three cost figures, and the specific assumption, an adoption count or an escalation rate, that would flip the recommendation.
05
Recommendation
The decision itself, written as a short architecture decision record, context, decision and consequences stated in both directions.
How it works
- 1
Open it in River, or download it
Edit with AI opens the pack as a private Space with the agent ready to price both sides. Download hands you two Word documents and three CSV sheets, no account needed.
- 2
Send the vendor's pricing and your build plan
The vendor's documentation and pricing page, plus whatever your own team can say about the build option: who would build it, roughly how long, and what maintaining something like it usually takes.
- 3
Get the maintenance priced by task
River asks for the recurring tasks, bugs, on-call, feature requests, security work, and prices each as a fraction of an engineer's time with its own growth curve, instead of a flat percentage.
- 4
See where the real total disagrees with the naive one
The Total Cost sheet reports the naive, heuristic and real build figures next to the buy figure, so a reversal between them is visible rather than buried in one final number.
Frequently asked questions
Is this template free?
Yes, and the download needs no account, card or email. Edit with AI is the optional half, where River builds the capability comparison, prices the build side's maintenance by task, and writes the recommendation from what you send it. The rest of the template library works the same way.
What format are the downloaded files?
Two documents as .docx and three sheets as .csv, in one zip. Word, Pages, Google Docs, Excel, Numbers and Sheets open them with nothing to convert. The sheets ship with the Cordata Systems worked example already filled in, so the naive, heuristic and real totals are visible before you replace them with your own numbers.
Isn't a flat percentage close enough?
It is what most guidance uses when it prices build maintenance at all: one framework budgets 10 to 20 percent of the build cost a year as a flat rate. In the worked example that heuristic prices three years of maintenance at $72,000 against a real, task-priced $201,600, a gap large enough to flip which option is actually cheaper.
Why record the recommendation as an architecture decision record?
Because a decision with no argument attached gets re-argued the day someone questions it. An ADR states the context, the decision in one or two sentences, and the consequences in both directions. For a fuller decision-record system across a whole codebase, use the architecture decision record template.
Does this replace our program management tool?
No. A vendor dependency worth tracking belongs in a technical risk register, and once a path is chosen, the engineering status update reports it upward. This pack is where the decision itself gets priced, before either of those starts.
How long would building it actually take?
This pack prices the decision, not the delivery date. Once you choose to build, forecasting when it actually ships from your own team's throughput is what an estimation and capacity forecast does, one step after this one.
Our vendor and cost data can't leave our network. Can we still use this?
Yes. A private AI workspace builds the capability comparison, the total cost sheet and the recommendation inside your own tenancy. No vendor contract, pricing detail or internal cost figure crosses a boundary your security team has not already reviewed and approved for planning data like this.