Build vs buy FP&A: what teams underestimate before they start

The line shows up at almost every board meeting I sit in on now. “We have engineers. Why don't we just build the FP&A stack ourselves?” It's a reasonable instinct. The team has shipping muscle, the requirements feel known, and every quote from Anaplan, Pigment, or Vena reads like a small mortgage. Building looks like the right move.

Eighteen months later, almost every team I've watched try this is quietly evaluating vendors again. I want to be careful here, because this is the kind of essay where a vendor's bias does most of the writing. So I'll lead with the case for building, and try to be specific enough that you can argue with me.

When building is actually the right call

Some teams genuinely should build it themselves, and the honest list is short. If you have spare engineering capacity that isn't tied to revenue features, or your needs are unusual enough that no vendor can model them, or you have a structural reason to own the IP - acquisition optionality, vendor risk policy, a board mandate - building is the right call. If two of those three are true for your team, you can stop reading. The math is on your side.

For everyone else, the question isn't really “can we build this?” The team you're talking about can almost certainly build a functional FP&A stack. The question is what it costs you to build it and keep it running, year after year, after the original engineers have moved on. That second half is where the math breaks.

What teams underestimate

The kickoff estimate is almost never the part that goes wrong. What goes wrong is everything that comes after launch, and it clusters in three predictable places.

None of these are problems you size correctly when scoping. They're problems you discover after launch, when the original engineers are off the project and maintenance is sitting on whoever's left. The 1-2 FTEs aren't a worst case; they're the steady-state cost of owning the system. The connector drift isn't a bug; it's the upstream vendors doing their job. The hiring problem isn't a reflection on your team; it's the labor market for a rare skill combination doing what labor markets do.

The 18-month pattern

The arc is consistent enough that I can write it from memory. Month zero is kickoff energy: two engineers staffed, a quarter blocked, a beautiful PRD. Finance is excited, eng is excited, and the CFO mentions it on the all-hands. Month six finds you fifty percent done. The data model works for eighty percent of cases, and the last twenty percent is where actual finance lives - the unusual entity, the off-cycle close, the consolidation adjustment that doesn't fit the schema. By month twelve, engineers are quietly being pulled back to revenue features, and the FP&A stack is “feature complete” in a Jira sense and never quite trusted by the team using it. Excel is still running the close. By month eighteen, someone in finance pulls up Pigment in a meeting and says, this is what we were trying to build. The internal stack gets renamed “legacy.” The original engineers have already moved on.

Build vs buy isn't a software question. It's an opportunity-cost question. Your engineers stop building the thing your customers pay you for.

The honest case for buying isn't that vendors do it better. Some of them don't. It's that the vendors are spending engineering hours you'd otherwise be spending elsewhere. Every vendor in this category is shipping AI, connectors, and modules you wouldn't have prioritized, and your team gets the upgrade for the price of a renewal. When the close breaks at 11 PM the night before the board meeting, there's a phone number to call. When your in-house stack breaks, there's a Slack channel and a hope.

Three checks before you commit a quarter

If you're at the start of this conversation, three questions worth running by your team before kickoff. Will the engineers who built it still be on it in eighteen months? If you can't name them and confirm with their managers, the answer is no, and your maintenance plan needs to assume that. Who maintains the GL connector when NetSuite changes its schema? If that role is unstaffed, the connector will break and stay broken until someone notices the variance numbers are wrong. And what does FP&A do during the twelve months between “we started building” and “it's actually trusted”? Same as before. Excel. Add a year of Excel-cost to your estimate.

I don't think there's a clever answer here. Build vs buy is mostly an opportunity-cost problem disguised as a software problem. When the build is right for your team, it's very right. When it isn't, the cost of pretending it is shows up at month eighteen, in a meeting where someone pulls up a vendor.

Novaplan is built around the case where buying is right but you're tired of vendors who treat your hierarchy as a phase-2 item. If you're at the start of a build conversation and you want a second opinion before you commit a quarter to it, talk to me. I'll tell you straight where building is the right call. Sometimes it is.