Build vs Buy Analysis Template

Joel Spolsky, a co-founder of Stack Overflow, put the rule bluntly in a 2001 essay: if it's a core business function, do it yourself, "no matter what."¹ A drug company, he wrote, should write software for its research but not its own accounting package.

Martin Fowler, chief scientist at the software delivery firm Thoughtworks, sorts systems into utility and strategic². Payroll is his classic utility: everyone needs it, and it just has to work. For a utility, he advises buying the package and changing your process to fit the software. He adds that only a few projects are strategic, perhaps 5 in 100, and that people tend to think too many are.

Before pricing either path, write down what the tool must do, so both are costed against the same list. A business requirements document gives you numbered, testable lines.

Read the contract, not the pricing page. Find how much the price can rise at each renewal, whether the contract renews on its own, and how much notice you must give to leave. Price each year at the most the contract allows; if there's no cap, pick an increase and label it.

Quotes leave things out. A free managerial accounting textbook from OpenStax, part of Rice University, lists outsourcing's drawbacks, among them hidden costs, unstable prices, and work that is hard to bring back in-house³. For software, look for these:

• Setup, data migration and training
• Running the old process alongside the new one until you switch
• Staff time to manage the tool and connect it to your other systems
• Extra seats, add-ons and usage charges as you grow
• The cost of leaving: exporting your data and any early-exit fee

If more than one vendor could do the job, ask each to quote against the same requirements. A short request for proposals puts their answers side by side, so you compare real quotes rather than list prices.

The build estimate is engineers times months times each engineer's fully loaded monthly cost: salary plus payroll taxes, benefits and equipment. Add a contingency for overrun, and state it.

Bent Flyvbjerg and Alexander Budzier, writing in Harvard Business Review in 2011, studied 1,471 IT projects, most of them large public-sector systems. Costs ran 27% over plan on average, but the worst one in six overran by an average of 200%⁴, finishing at about three times their budgets. Test the bad case, not just the average.

Then count the years after launch. The US Government Accountability Office reports that federal agencies have typically spent about 80% of their IT budgets running and maintaining the IT they already have⁵. Use your own upkeep history if you have one; if not, pick a yearly rate, such as 20% of the build cost, and count it from go-live. Include hosting, security fixes and support.

Finally, price what the build pushes back. While engineers build an internal tool, the roadmap waits. Their pay is already in the estimate, so add only what their usual work earns above that pay, for each engineer-month. Adding its full value on top would count the same months twice.

If no one can value that work, the tipping-point test below shows the value that would change the answer. Contractors hired for the build take nothing from the roadmap: their invoices are the cost.

Count the months without the tool. Ask the vendor how long setup takes at your size, and compare that with the build's schedule plus its contingency. Each month the old workaround continues costs staff time, and you can price it.

Before you sign, find out how you would leave: whether you can export all your data in a usable format, and how long the term ties you in. A vendor risk assessment checks the vendor's security report against what you will rely on.

A build has its own lock-in: the people who wrote it. If one engineer understands the tool, it is at risk the day they leave, so budget for documentation and a second owner.

Lay both paths out year by year, with the naive comparison beside the full one. Then change one input at a time to find the value where the answer flips: the tipping point.

Take an illustrative 150-person company that needs a tool to route and approve purchase requests. The vendor quotes $60,000 a year, with renewals that can rise up to 10% a year, $8,000 for setup and migration, and no fee to leave. The engineering lead estimates two engineers for three months at $16,000 per engineer-month, fully loaded. Their roadmap work earns about $9,000 per engineer-month above that.

Put the result on one page: both totals, the naive view, the tipping points and the reasons money can't capture. If your engineers keep architecture decision records, log it there, so the next team can see what would justify reopening it. Set a review date before the vendor's renewal notice deadline.

The tool at the top of this page runs this comparison for you. Paste the vendor's quote and your build estimate, and it prices both paths year by year, labels every assumption and finds the tipping point.