Build vs. Buy Software: A 36-Month Cost Model

Build or buy starts with the constraint

A build versus buy software decision is not really about software. It is about control, speed, and the cost of being wrong.

Buy when the capability is standard, the vendor gets you moving quickly, and owning the code would not improve your economics. Build when the workflow is a real source of margin, speed, trust, or something hard for a competitor to copy. If the answer still looks close, model both paths over the same time period and write down what must be true for the custom build to win.

The mistake is comparing a vendor's monthly fee with a developer's first quote. Those numbers do different jobs. One is a recurring price for a working product. The other is the opening cost of becoming a software owner.

Name the job before comparing tools

Write one sentence that defines the outcome.

Not "we need a new operations platform." That is already halfway to a solution.

Try this instead:

We need to move an approved customer order from payment to fulfilment with one accountable owner, a complete audit trail, and no manual re-entry.

That sentence gives you something to test. A vendor can demonstrate whether its product handles the job. A build team can estimate the missing work. Everyone can see where the workflow begins and ends.

Now name the constraint that makes the decision matter. It may be time to launch. It may be a workflow that no standard product handles. It may be data control, complex integration, reliability, or the cost of changing the process around a vendor.

This is the same discipline behind our research method. Start with how the operation actually behaves. Then find the constraint that changes the economics.

Compare the same cost stack

A useful model includes every cost created by the decision. The line items differ, but the jobs do not.

Do not hide internal time because nobody sends an invoice for it. A manager spending a day each week fixing imports is a cost. So is an engineer keeping an old integration alive. The spreadsheet does not care whether the bill arrives from a vendor or from payroll.

Use one decision horizon for both options. Thirty-six months is often long enough to expose recurring costs without pretending you can forecast forever. That is an editorial choice for this model, not a universal rule. Use the horizon that fits the actual decision.

A worked 36-month example

The figures below are a hypothetical example, not market benchmarks or a quote. They exist only to show the math.

Assume a company needs an internal workflow system.

Buy option assumptions

• Vendor implementation: $24,000
• Licence: $4,500 per month
• Internal administration: $1,500 per month
• Migration and cleanup: $18,000

The 36-month cost is:

• Licence: $4,500 × 36 = $162,000
• Internal administration: $1,500 × 36 = $54,000
• Total: $24,000 + $162,000 + $54,000 + $18,000 = $258,000

Build option assumptions

• Initial design and build: $210,000
• Cloud and tools: $2,000 per month
• Maintenance and internal ownership: $7,000 per month
• Security and reliability review: $30,000

The 36-month cost is:

• Cloud and tools: $2,000 × 36 = $72,000
• Maintenance and ownership: $7,000 × 36 = $252,000
• Total: $210,000 + $72,000 + $252,000 + $30,000 = $564,000

In this example, building costs $306,000 more over three years. That does not automatically make buying right. It tells you what the custom system has to earn back.

Suppose the custom workflow creates an incremental benefit of $9,000 per month compared with the vendor. Again, that is an assumption for this example. The simple payback on the extra build cost is $306,000 ÷ $9,000 = 34 months.

That leaves little room for delay or disappointment inside a 36-month horizon. The build case is weak unless the advantage lasts longer, grows, or protects something the simple model has not priced.

This is nominal arithmetic. It does not include financing, tax, inflation, discount rates, or the probability that an estimate is wrong. Bring qualified finance, tax, and legal professionals into a real decision where those issues matter. This article is a framework, not investment, tax, or legal advice.

Price the delay

Time belongs in the model.

If buying gets the workflow live six months earlier, ask what those six months are worth. Count avoided manual work, earlier revenue, fewer errors, or a faster learning cycle only when you can support the assumptions from your own operation.

Do the same for the vendor path. A product that looks ready may still need migration, configuration, procurement, security review, training, and integration, so give the buy path a realistic schedule for that work too.

Create three dates for each path:

1. The date a narrow pilot can run
2. The date the main workflow can move
3. The date the old process can be retired

The gap between those dates is where transition cost lives. Running two systems at once can create duplicate work, confused ownership, and records that disagree.

Price the uncertainty

A single estimate creates false confidence. Use a range for the major uncertain inputs.

For a build, test at least:

• initial scope and delivery time
• monthly maintenance
• hiring or contractor continuity
• integration and migration effort
• security and reliability work
• the cost of requirements changing

For a purchase, test:

• usage growth
• higher plan or support tiers
• paid configuration
• internal administration
• contract and renewal terms
• integration work and exit cost

Then ask which input can reverse the answer.

If the buy option wins unless licence cost doubles, the decision may be stable. If a four-week build delay changes the result, it is fragile. A fragile decision needs a smaller commitment and faster evidence, not a more decorative spreadsheet.

Our reverse-engineering playbook uses the same move. Find the assumption carrying the weight. Test that one first.

Know what deserves custom ownership

Custom software is easiest to justify when the capability changes how the business wins.

That can mean:

• a workflow that directly improves margin or speed
• data or feedback loops competitors cannot easily copy
• trust, safety, or quality controls that must fit the product closely
• integration across systems where handoffs create the real cost
• a product experience customers pay for

Commodity work usually points the other way. Payroll, basic accounting, standard communication, and ordinary document storage are hard places to earn a return from custom ownership. The exact answer still depends on the operation, but our default is simple. Do not build a software company inside your company for a capability that does not make the company better.

The work we do covers both research and execution because this decision cannot end with a preference. Somebody has to own what happens next.

The hybrid option is often the real answer

Build versus buy is not always a clean fork.

A company can buy the standard core and build the narrow layer that creates leverage. Use a vendor for records, permissions, billing, or communication. Build the workflow, decision engine, automation, or interface that is genuinely specific.

This approach can reduce the amount of code the company owns while keeping control of the part that matters. It also creates a new question. Can the custom layer survive if the vendor changes an interface, price, term, or product direction?

Treat that dependency as a real design constraint. Keep data exportable. Document the boundary. Decide what happens when the vendor is unavailable. Review the governing contract and technical terms with qualified professionals before relying on access or portability rights.

Write the decision memo before approval

A good build versus buy memo can fit on a few pages. It should contain:

1. The job. The operational outcome in one sentence.
2. The constraint. The reason a standard answer may not work.
3. The options. Buy, build, and a serious hybrid.
4. The cost model. The same horizon and cost areas for each.
5. The uncertainty. The inputs most likely to change the result.
6. The decision rule. What must be true for the chosen path to win.
7. The kill criteria. The evidence that stops or redirects the work.
8. The owner. One person accountable for the result after launch.

Write the kill criteria before approval. A build might stop if a pilot misses a delivery date, cost ceiling, or required workflow. A purchase might stop if migration fails, the contract leaves a critical dependency exposed, or the product cannot handle the tested process.

The exact criteria must come from the real operation. Do not borrow impressive thresholds from somebody else's company.

Make the smallest reversible move

When the evidence is incomplete, reduce the commitment.

Run the vendor against a difficult real workflow. Build a narrow prototype around the part vendors fail. Test data export before signing. Put one integration under load. Measure the internal work a demo quietly ignores.

The goal is not to prove your preferred option. It is to make the next mistake cheap.

That is how we approach new business and operating decisions. The answer may be buy, build, combine both, or leave the process alone. The useful result is not custom software. It is a better operation with ownership, cost, and risk visible before the commitment gets expensive.