The Cost of the Architecture: Financial Modeling as a Core IT Competency

The Question Architecture Proposals Usually Don't Answer

Picture a 90-person law firm whose ops lead recommends migrating case management to a new SaaS platform. The pitch is a clean comparison: the new platform starts at a few hundred dollars a month, versus the aging incumbent's clunkier interface and higher support costs. It looks like an easy call — until, buried in the incumbent's exit terms, is a $40,000 data-migration and de-conversion fee the firm would owe if it ever needed to leave. Nobody modeled that number before the original decision to adopt the incumbent five years ago either — which is exactly how the firm ended up here.

When a technology decision reaches leadership, it typically arrives already framed as a technical choice: "we recommend Platform A over Platform B," "we should migrate to the cloud," "we're proposing to build this internally rather than buy it." The technical reasoning is often sound. What's usually missing is the financial reasoning underneath it — not the sticker price, which is easy to find, but the shape of the cost over time, under the company's actual growth trajectory.

This gap exists because architecture decisions get evaluated by the people best equipped to judge technical fit, and financial modeling isn't traditionally part of that skill set — nor should it need to be. The problem isn't that engineers are bad at financial modeling. It's that no one is asking the financial question before the decision gets made, because architecture and finance are treated as separate conversations that happen to intersect at budget approval, rather than one conversation that should happen together from the start.

The Obligation, Not the Cost

An architecture decision isn't a purchase — it's an obligation. Every design commits the business to a future state: what it will cost to run, what it will take to change, and what it will cost to leave, over the next three, five, or more years. The architect's job isn't finished when the system works. It's finished when that obligation has been named and explained to the people who'll be living inside it.

That's also where the integrity of the pitch actually lives. Anyone can tell you what something costs today — that number is easy, and it's not where the risk is. Whether someone is willing to name what it obligates the business to tomorrow, the multi-year commitment sitting underneath the contract, says more about whether their recommendation can be trusted than the recommendation itself does.

Asking what a decision costs at year one, year three, and year five isn't the point. It's just the method — the way you drag an unstated obligation into the open before you've signed it.

Most technology costs are not flat. A SaaS platform priced per seat looks affordable at 30 employees and materially different at 150. A cloud infrastructure bill that's negligible at current traffic can become one of the largest line items in the technology budget once usage scales — the usual cause isn't the pricing model itself, it's the absence of active cost governance: no resource tagging, no reserved-capacity planning, no one who owns watching the bill. A "free" open-source tool has real costs in the staff time required to maintain it, which shows up nowhere in the initial proposal.

None of this means the decision was wrong at the time it was made. It means the decision was evaluated against today's numbers, for a company that won't be the same size in three years.

There's usually a technical tell that predicts which decisions will age badly, before the invoice does: how tightly the platform's data schema and workflows are coupled to that one vendor's way of doing things. A tool that stores data in an open, exportable format and integrates through a documented API is expensive to leave in theory but usually cheap in practice. A tool that owns your data model — where "your" case files or customer records only make sense inside that vendor's proprietary structure — is the one where the exit fee shows up later as a surprise. That's a technical read, not a financial one, and it's usually visible before the contract is signed, if anyone's looking for it.

Where This Matters Most: Build vs. Buy

The build-versus-buy decision is where the absence of financial modeling causes the most damage, because the two options present their costs in fundamentally different, hard-to-compare ways.

"Buy" has a visible, quotable price — a monthly or per-seat subscription that's easy to put in a spreadsheet next to a competing quote. What's harder to see, as the law firm above found out, is the exit cost: data migration, de-conversion fees, retraining, integration rework. A per-seat SaaS tool that costs a few hundred dollars a month at 20 users can also become one of the largest recurring line items in the budget at 200 — the pricing model is often designed to be attractive at small scale and expensive at the scale the company is trying to reach.

"Build" has the opposite visibility problem: no per-seat scaling cost and no vendor exit fee, but real costs that rarely make it into the initial pitch either — ongoing maintenance burden, the opportunity cost of engineering time that isn't going toward the company's actual product or operations, and bus-factor risk if the one person who understands the system leaves. Build isn't immune to lock-in either — it just wears a different disguise, as technical debt: a system nobody but its original author fully understands is exit-locked in its own way, just without a vendor invoice to make the cost visible. For most companies in the 25-200 employee range, "buy" is still the right default specifically because they can't staff an ongoing maintenance function — the lock-in risk is real, but it's usually the smaller of the two risks.

A financial model doesn't automatically favor build or buy — it depends entirely on the company's specific growth trajectory and risk tolerance. What it does is make both sides of the tradeoff visible before the decision is locked in, rather than three years later when the company is deep enough into one path that changing course is its own expensive project.

The Questions Leadership Should Be Asking

Before signing off on a significant architecture decision, a leadership team is well-served asking:

• What does this cost at our current scale, and what does it cost at 2x and 5x our current scale?
• What's the cost of switching away from this later, if we need to? (Vendor lock-in, data portability, and migration effort are real costs, even when they don't show up on an invoice.)
• What staffing or skill implications come with this choice — does it require expertise we have, or expertise we'd need to hire or contract for?
• What's the cost of doing nothing, or delaying this decision by a year?

Few technical proposals answer these unprompted. That's not a failure of the people writing them — it's a sign the questions were never built into the process. None of this means every decision needs a full financial model — a five-minute back-of-envelope version is enough for a low-stakes choice. It's the decisions with real dollar or risk exposure, like the firm's case-management platform, that warrant the fuller version.

Why This Belongs With Someone Who Owns Both Sides

The fix isn't asking engineers to become financial analysts, or asking finance to start evaluating architecture diagrams. It's putting financial modeling into the standard workflow for any technology decision above a meaningful dollar or risk threshold, owned by someone accountable for both the technical soundness and the financial shape of the outcome — not just the person who happens to be in the room when the decision gets made.

That's a governance gap more than a skills gap. Most growing companies already have people capable of building the technical case and people capable of building the financial case. What's usually missing is a process — and someone senior enough to own it — that requires the two to sit in the same room before the decision, not after the invoice.

You don't have to become a financial analyst to make this call correctly — you just have to insist someone in the room is doing this math. If your last major architecture decision didn't come with a cost curve attached, the next one should. Subscribe for more like this.

This article was drafted with AI assistance and reviewed and edited by Matt before publishing.

About the Author: Matt Shirel writes Praxis CTO, exploring what real technology leadership looks like for growing companies that have outgrown ad hoc decision-making. He brings over 20 years in enterprise IT — spanning infrastructure architecture, cloud strategy, and technology budget ownership — and works hands-on in applied AI, building multi-agent and RAG workflows with tools like n8n and AI coding agents. He started Praxis CTO to make the case, in public, for treating architecture decisions with the same financial rigor this article argues for.