What Boards Should Demand Before Approving a Build-Versus-Buy Call
The Governance Gap in Most Build-Versus-Buy Approvals
A build-versus-buy proposal that reaches the board usually arrives with a clean recommendation and two comparable-looking numbers. What the board often doesn't see is how much of the real cost, the integration work, the training, the years of maintenance, sits outside those two numbers entirely. That's not a failure of the people presenting; it's a governance gap in what boards typically ask for before they approve.
Why Should the Board Be Involved in This Decision at All?
Boards should be involved when the decision is large enough to materially affect the technology budget or the reinsurer's operating capability, since an incomplete cost view at that scale is a governance risk, not just a project risk.
Smaller, lower-stakes technology decisions can reasonably stay at the management level. A major platform decision, the kind that will shape how the reinsurer operates for the next five to seven years and consumes a meaningful share of the technology budget, deserves board-level scrutiny of the numbers behind it, not just the recommendation itself.
What Should the Board Require Before Approving a Major Decision?
A documented total-cost comparison covering multi-year implementation and maintenance costs for both options, not just the headline license price or development estimate.
SimpleSolve's research puts a hard number on why this matters: "purchase price is often just about 10 percent of the actual cost of implementation." A board approving a decision based on that 10 percent alone is approving something very different from what it thinks it's approving.
How Can the Board Tell If a Total-Cost View Is Genuinely Complete?
Ask specifically whether integration, training, and multi-year maintenance were included in the comparison, since these are the categories most often left out of an incomplete estimate.
A vague assurance that "we've looked at the full cost" isn't enough. Asking for the specific categories by name forces whoever is presenting to confirm, item by item, that the comparison is actually complete rather than just described as complete.
| Board Question | What It Tests |
|---|---|
| Was integration cost included? | Whether the estimate covers connecting to existing systems |
| Was training cost included? | Whether staff time to adopt the new system is accounted for |
| What's the multi-year maintenance estimate? | Whether ongoing cost, not just implementation, was modeled |
| What horizon does the comparison cover? | Whether backloaded costs are visible |
What Governance Gap Does Skipping This Review Create?
It creates a gap where technology spending decisions with years of downstream cost get approved based on a fraction of their real financial impact, without the board realizing the comparison was incomplete.
This is a quiet gap, because nothing about the approval process feels wrong at the time. The proposal looks thorough, the recommendation looks reasonable, and the board approves in good faith. The gap only becomes visible years later, when actual spend has diverged significantly from what was originally approved, by which point attributing the variance back to an incomplete initial comparison is much harder.
Should the Board Require a Specific Cost Horizon?
Yes, a minimum five to seven year horizon is a reasonable requirement, since shorter horizons can make backloaded costs, like vendor renewal escalators, invisible at approval time.
A comparison limited to year one or two can make a vendor option look artificially attractive if its pricing escalates significantly after an initial period, or make a build option look artificially expensive if its main costs are concentrated upfront rather than spread out. A longer horizon corrects for both distortions.
What Follow-Up Should the Board Require After Approval?
Require periodic reporting comparing actual cost against the approved total-cost estimate, so variance is visible to the board before it becomes a much larger problem.
Approval shouldn't be the last time the board sees this decision. A Reinsurance Audit Preparation AI Agent can help management prepare consistent, comparable variance reports for this kind of ongoing board review, rather than reconstructing the comparison from scratch each time it's requested.
What's a Red Flag in a Proposal Presented to the Board?
A red flag is a proposal that presents only a single upfront cost figure per option without breaking out integration, training, and multi-year maintenance separately.
When a comparison is reduced to two clean numbers, that simplicity should raise a question rather than provide comfort. Real total-cost comparisons are rarely that tidy, because the categories that matter most, integration and maintenance, are inherently harder to pin down to a single figure.
A board that only reviews the headline numbers in a build-versus-buy proposal is reviewing the smallest, easiest part of the real decision. The larger part, the years of cost that follow implementation, deserves the same level of scrutiny before approval, not a post-mortem explanation after the budget has already run over.
Frequently Asked Questions
Why should the board be involved in a build-versus-buy decision at all?
Boards should be involved when the decision is large enough to materially affect the technology budget or the reinsurer's operating capability, since an incomplete cost view at that scale is a governance risk, not just a project risk.
What should the board require before approving a major build-versus-buy decision?
A documented total-cost comparison covering multi-year implementation and maintenance costs for both options, not just the headline license price or development estimate.
How can the board tell if a total-cost view is genuinely complete?
Ask specifically whether integration, training, and multi-year maintenance were included in the comparison, since these are the categories most often left out of an incomplete estimate.
What governance gap does skipping this review create?
It creates a gap where technology spending decisions with years of downstream cost get approved based on a fraction of their real financial impact, without the board realizing the comparison was incomplete.
Should the board require a specific cost horizon for the comparison?
Yes, a minimum five to seven year horizon is a reasonable requirement, since shorter horizons can make backloaded costs, like vendor renewal escalators, invisible at approval time.
What follow-up should the board require after approval?
Require periodic reporting comparing actual cost against the approved total-cost estimate, so variance is visible to the board before it becomes a much larger problem.
What's a red flag in a build-versus-buy proposal presented to the board?
A red flag is a proposal that presents only a single upfront cost figure per option without breaking out integration, training, and multi-year maintenance separately.
How does this oversight connect to broader technology risk appetite?
It connects directly, since approving decisions on incomplete cost data means the board is unknowingly accepting a wider range of financial outcomes than its stated risk appetite would normally allow.
