How to Price a Build Decision Before It Prices You

It always starts the same way: the internal team says it can build this in-house, the initial number works, it's "only" two or three developers for a few months, no third-party fees. Finance approves because we're optimizing direct cost, which is the most basic thing we get paid to watch.

Nine months later the product exists, but it barely walks. And even though nobody says it out loud, everybody knows it has to be rebuilt.

That's when three costs show up, and no report separates them properly.

1. The rebuild itself. You pay twice for the same functionality, and by that point you've already capitalized it on the balance sheet as though it were an asset.
2. Opportunity cost. It never appears as a line item and is almost always larger than the rebuild, because it covers the nine months your competitor spent in market and you didn't.
3. The sunk cost, which is the worst of them. You've already invested, already defended the decision to the board, already put your name on it, so killing it now feels like admitting the mistake. You back it instead, add one more developer, give it "a quarter to stabilize."

I wrote about this on LinkedIn a few weeks ago. I expected the replies to be about that sunk cost, and almost all of them were about something else: how to avoid getting there. Finance leaders and a couple of operating partners asked me, in different words, the same practical question. All three costs surface at the end while the approval happens at the beginning, so what specific numbers should they be asking the team for at that point, when nothing has been built yet and direct cost is the only figure anyone has put in the spreadsheet?

What the approval model gets right, and what it leaves out

The standard approval model deserves a defense before anyone criticizes it. When a team proposes building something internally and the estimate comes in at two or three engineers over a few months with no license fees attached, that estimate is usually accurate for the median project. Most software work lands somewhere near where it was scoped, and finance approves it on that basis for perfectly sound reasons.

What the model handles poorly is that the range around that median is skewed. What I mean is that when a build goes well, the savings are modest, but when it goes badly, there is no ceiling, because the failures compound instead of adding up. For example, one integration nobody scoped pulls the authentication layer and two reporting jobs in with it. Or a data migration that was supposed to take two weeks, reveals that the source system holds four years of records nobody can reconcile. By the time any of that surfaces in a status report, the calendar has already moved.

AI initiatives produced a version of this at scale. Plenty of them were built in-house with real goodwill and not much expertise, and it shows when the finished thing turns out to be a pile of spreadsheets on steroids. Read that as a finance person rather than a technologist: the work was staffed, capitalized, defended in a budget cycle before anyone was willing to say it had not worked. The arithmetic in the approval model was never the problem. What it fails to account for is how far the real cost can move from the original estimate when things go wrong.

Three numbers that belong in the model before anyone builds

These numbers are often missing because the person assembling the business case was asked what it costs to build, rather than what it costs to be wrong. And those two questions are usually answered by different people.

• The cost of getting it wrong. If the chosen path is building with the internal team, finance should ask engineering to estimate the probability that the product will need to be substantially rebuilt. Expect some pushback, because putting a number on that risk means acknowledging how much uncertainty is actually in the plan. Once you have that estimate, capture both sides of it in the business case. If a $1 million build carries a 20% probability of requiring another $1 million to rebuild, the expected cost is $1.2 million. But finance should also show the full downside: if that risk materializes, the company is looking at a $2 million project. Engineering estimates the probability and the cost of a rebuild. Finance decides how that risk is reflected in the model.
• The cost of delay. A build can stay within its engineering budget and still cost the company money by arriving late. Finance should put a value on that delay, especially when customers are already waiting for the capability or competitors have already brought something similar to market. Estimate the revenue at risk for each quarter the capability is delayed and include it in the business case alongside the build cost. The number does not need to be exact. Even a reasonable estimate makes the trade-off visible and gives finance something concrete to compare.
• The cost of owning it after launch. Every path carries an ongoing cost. An internal build requires engineering capacity to maintain the software, support it, and preserve the knowledge needed to keep it running. An outside team may shift some of that responsibility into a support or maintenance agreement, while a purchased product brings recurring license and vendor costs. The relevant number for finance is the total cost of ownership after launch, including who will maintain the capability, what that will cost each year, and how much of that responsibility remains with the company.

That last one is what I see left out most often, and it's the one that quietly compounds. A build approved as a one-time investment becomes a recurring cost the following year, and it enters the P&L without anyone having decided to put it there. The same is true of a subscription that grows with headcount. Neither shows up in the comparison that got the decision approved. 

Writing the exit before there is anything to defend

Here's the part that actually keeps the sunk cost from forming.

Once someone has sponsored a project and defended it to the board, it becomes harder to assess objectively whether it should continue. That is why the decision to stop or reassess should be defined upfront, before reputations and sunk costs become part of the equation. Set clear thresholds in the approval document so the project can be reviewed against agreed criteria later.

I made a related argument in a piece on the financial questions every AI implementation has to answer, where the idea was reversibility, designing the implementation so autonomy scales gradually and the thing can be walked back. Same principle, applied earlier in the sequence.

A usable exit condition is specific and dated. Not "we'll reassess in Q3." Something closer to this:

• If there's no working version running in a production environment by the end of month four, the build stops and we evaluate what to buy.
• If post-launch maintenance is trending above one full-time engineer, ownership moves outside or the capability gets replaced.
• If the process this was meant to shorten hasn't measurably shortened by month six, the project closes.

One detail matters more than the wording: the check has to be run by somebody other than the project sponsor. Hand the sponsor the job of reporting against a threshold they set themselves and you've recreated the original problem with extra paperwork. In our case that job sits with finance. It's uncomfortable about once a year, and worth it every time.

The objection that always comes up is that this puts an artificial ceiling on a team that might be two weeks from cracking it. That's a legitimate objection and the answer isn't to wave it off. Crossing a threshold doesn't force a shutdown, but a re-approval, with the number updated and with information that didn't exist when the thing was signed. If the case still holds, the work continues. The difference now is that continuing becomes a decision rather than inertia.

Most of these conditions will never get invoked, and that's fine. What they buy you is a hard conversation about a threshold everybody signed off on in advance, instead of a hard conversation about whose judgment failed. It takes somebody's reputation out of the decision, which is the whole point.

Where the arithmetic ends and strategy begins

Everything above helps you compare the financial cost and risk of each option. Choosing the right path requires a strategic question: how much of the company’s competitive advantage depends on this particular piece of software? We work through that question in detail in Build, Buy or Extend, with the criteria and a matrix for comparing them. 

Building is the right call when the capability is something customers actually pay for. If the software is the product, or it's the part of the process that sets the company apart, there's no reasonable alternative: you either buy a generic version of your own advantage or you build it.

There's one thing I'd add from the finance seat, and it concerns the third path: bringing in an outside engineering team. In my experience, this is where agreements are most often structured poorly.. If it's structured around bodies and hours, what you bought is staffing, and delivery risk stayed entirely with you while all you moved was the payroll. Tie it instead to a defined outcome, with someone accountable for it and the same exit conditions you'd attach to an internal project, and part of that risk genuinely moves. That difference is worth more than any rate comparison, and it's the first thing to disappear once the conversation moves to procurement.

What the finance seat contributes here

Finance adds the most value before a build decision reaches the approval stage, by making sure the business case is built around the right question. Too many build decisions move forward before anyone has clearly defined the problem, identified which existing systems already touch it, or agreed on the outcome that needs to change. At Making Sense, discovery happens before anything gets proposed for exactly that reason. Changing direction at this stage is far less expensive than doing it once development is underway. . The financial logic is simple: you can’t properly evaluate the cost of an option until you’ve clearly defined what you’re solving for.

CFOs learn to read a P&L with an eye for the costs that don’t appear as explicit line items. A build decision gives finance a chance to surface those costs before they become real: the cost of getting it wrong, the cost of arriving late, and the conditions that would justify stopping.

If this was worth your time, our monthly newsletter brings you more perspectives from across the team on the decisions mid-market and PE-backed companies are actually working through. Subscribe here.