River
Y CombinatorBacked by Y Combinator
Log InStart Free
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.

Edit with AIDownload (.docx + .csv)

Free download  ·  No account needed

What you get

Pack of 5 files: 2 documents, 3 spreadsheets

Build vs Buy Technical Decision Template
  • Decision AnalysisDocument
  • RecommendationDocument
  • Capability ComparisonSpreadsheet
  • Total Cost over Three YearsSpreadsheet
  • Switching Cost EstimateSpreadsheet
RiverBuild vs Buy Technical Decision Template

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.

Naive

The build estimate alone. No maintenance line at all, so this is the number a first comparison reaches for.

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.

Naive and heuristic both say build. Priced by task, buying is $88,000 cheaper.

The Total Cost comparison, the task-priced maintenance behind it, and the Switching Cost Estimate.

Build vs Buy Technical Decision Template
RiverTotal Cost, Build vs Buy

Total Cost over Three Years

Cordata Systems, a fictional B2B software company, feature flag and experimentation platform. Fully-loaded engineer rate $180,000/year.

MethodBuild TCOBuy TCOWhat it says
Naive (build cost only)$132,000$245,600Build looks cheaper by $113,600
Heuristic (flat 20%/yr)$204,000$245,600Build still looks cheaper by $41,600
Real (task-priced)$333,600$245,600Buy is actually cheaper by $88,000

The naive and heuristic methods both recommend building. Pricing maintenance by task reverses it: buying is 26.4 percent cheaper over three years.

Where the $201,600 of real maintenance actually goes

YearBugs & depsOn-callFeature reqsSecurityTotal FTECost
10.100.040.100.040.28$50,400
20.120.050.160.050.38$68,400
30.140.050.220.050.46$82,800

Feature requests grow from 0.10 to 0.22 of an engineer as three more product teams adopt the service, the same roadmap demand a vendor already spreads across its whole customer base.

RiverSwitching Cost, Both Directions

Switching Cost Estimate, both directions

What each option costs to leave, not just to adopt.

DirectionCost itemAmount
Leaving Flagcastle1.5 engineer-months to export data and rebuild the integration$22,500
Leaving FlagcastleContract data-export fee$8,000
Leaving FlagcastleTotal$30,500
Decommissioning the build4 engineer-months to migrate dependent teams off safely$60,000
Decommissioning the buildData migration$10,000
Decommissioning the buildTotal$70,000

Decommissioning the build costs more than twice as much as leaving the vendor. A percentage-only comparison never has to price this side, so build reads as the lock-in-free option by default. It is not, once someone actually prices the exit.

Edit with AI

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. 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. 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. 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. 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.

Sources

  1. IdeaPlanBuild vs. Buy vs. Partner Decision Template (opens in a new tab)
  2. Cognitect.comDocumenting Architecture Decisions (opens in a new tab)
  3. Intelligent Graphic & CodeBuild vs Buy Software: Decision Framework for 2026 (opens in a new tab)

Written by

Chandler Supple

Co-founder & CEO, River

Chandler has spent the last six years working in AI, building tools for millions of users and Fortune 100 companies. In 2025, he co-founded River to build a new kind of operating system for AI agents.

LinkedInGitHubX

Reviewed by

Brian Joseff, Co-founder, River

LinkedInX

More free templates

Cross-Team Dependency Negotiation Template

A cross-team dependency template that checks a provider team's stated confidence against its own historical rate at that same confidence level.

Engineering Capacity Planning Template

A capacity planning template that forecasts delivery as a P50/P85/P95 range from measured throughput, not a roster hours-minus-PTO calculation.

Engineering Project Retrospective Template

A project retrospective template that attributes delay to ticket history and the scope change log, not to what the retro meeting remembers.

Production Readiness Review Checklist

A production readiness review checklist that separates checked from evidence-attached from verified, so a launch cannot pass on a self-reported tick alone.

Price the maintenance before the decision, not after

Edit with AI