Build vs Buy Decision for CRE Underwriting Software

The build vs. buy decision for CRE underwriting software gets treated like a technology question, but the math underneath it is really about total cost of ownership, and most people answer it before they've actually done that math. Build it yourself and you inherit a maintenance job nobody wrote a headcount for. The timing makes this worse than usual: $957 billion in CRE loans matured through 2025, another $1.5 trillion comes due in 2026, and new loan volume was already up 13% at the start of the year, more than 90% above 2024 by Deloitte's count. Nobody gets to pick between speed and volume anymore. You need both, and the underwriting stack built for a slower market is now the thing standing in the way.

What CRE underwriting software actually does inside a deal workflow

The software sits between a stack of deal documents and the credit committee meeting where somebody has to actually decide something. Rent rolls, operating statements, appraisals, borrower financials, environmental reports, all of it pours in, and the job of the software is to turn that pile into something a human can act on without losing a weekend.

In practice that means document ingestion with citations back to the source page, financial spreading that maps raw numbers onto the firm's own templates, policy exception flagging against lending criteria, risk scoring across credit, market, property, borrower, and deal structure, stress-testing for rate shocks and occupancy dips, and drafting the credit memo. The software compresses the grunt work of data assembly, but the underwriter still validates, still exercises judgment, and still makes the final call.

Three waves got us here. Spreadsheet calculators first, which were just faster arithmetic dressed up. Then structured extraction tools, mostly for multifamily, where rent rolls at least follow a familiar shape. What's running now parses whatever document format shows up, reconciles conflicts when two sources disagree, and pulls in live market data without anyone retyping numbers into a template. The speed gap isn't subtle: AI agents process documents in 1 to 3 minutes, where doing it by hand runs 30 to 40 minutes per document. That's an order-of-magnitude difference in throughput per analyst.

Worth flagging before anyone gets too excited about any of this: a lot of what gets marketed as "AI underwriting" is really one trick performed well. Rent roll extraction here, comp gathering there, a single task automated in isolation. Fine, as far as it goes. But it changes the math, because a tool that does one step well still leaves you stitching the rest of the workflow together yourself.

Where the build instinct comes from and why it is often wrong before the analysis starts

The case for building sounds airtight the first time somebody says it out loud in a strategy meeting. Proprietary workflow as competitive moat. Full control over data, logic, roadmap. No per-seat pricing creeping up as headcount grows, no vendor holding your data hostage. None of that is wrong, exactly. It's just half the ledger, the half that only counts what ownership gives you and skips what it costs to build and keep.

So here's the actual fork: is your underwriting workflow a genuine moat, or a commodity function with your firm's templates bolted on top? Most teams answer "moat" on reflex, without ever testing the claim against anything. Try this instead: if the logic is truly proprietary, can you say precisely how it differs from what a purpose-built vendor already coded into their product? If the answer goes vague around the third sentence, the moat was never there. It's just a spreadsheet everyone's gotten attached to.

The adoption numbers make the gap visible in an almost embarrassing way. Deloitte found 76% of CRE firms are exploring or implementing AI in some form. McKinsey's July 2025 survey put actual gen AI deployment at North American banks at 12%. That's a lot of daylight between intent and shipped product, and the gap points to how difficult it is to move from exploring AI to actually deploying it.

The hidden difficulty of building for CRE document variability

The hard problems never show up on the whiteboard. They show up eight months into the build, when somebody discovers that broker number four formats their offering memorandum in a way absolutely nobody planned for.

Document variability is the whole ballgame. Every broker builds an OM differently: cap rate tables land on page 3 in one and page 22 in another. T-12 statements come in dozens of variations, and rent rolls have no standard shape at all since every property management system spits out something slightly different. Manual extraction isn't even a clean baseline worth beating: it runs 35 to 120 minutes per dataset and still produces 8 to 10 wrong entries per 100 data points. Building extraction alone doesn't solve this. Quality assurance has to sit on top of it, because the thing you're trying to replace was already error-prone to begin with.

Vendors who specialize in CRE have spent years feeding models this exact mess. A firm starting today isn't closing that gap so much as opening a new one and racing to fill it before the market shifts again. V7 Labs put AI lease-abstraction accuracy at 95%, and that number is the product of years of domain training, not something a team knocks out in a sprint or two. Sitting on top of the extraction problem is a quieter second one: a firm's own underwriting templates and add-back conventions have to survive contact with all this variability. That's a CRE-specific calibration headache, not a general machine learning problem, and it needs continuous tending as document formats and lending policy shift under it.

The API call to a foundation model looks cheap. The real accounting starts well past that point.

What building actually costs when you account for everything

The number people quote for building custom underwriting software runs $30,000 to $500,000-plus depending on scope and team, with enterprise-grade platforms carrying compliance and AI features sometimes topping $1 million. That figure is also, reliably, the smallest one in the whole exercise.

Annual maintenance runs 15% to 25% of the original build cost, every year, forever. A $500,000 build carries $75,000 to $125,000 a year in upkeep before anyone writes a single new feature. Add cloud hosting at $2,000 to $10,000-plus annually. Add a discovery phase of $5,000 to $15,000 before a line of code exists. Stack the hidden costs on top: maintenance, technical debt, hiring, compliance work, and the effective three-year total roughly doubles what the initial proposal promised.

Then there's time. Custom enterprise platforms typically take 7 to 14 months before first deployment. That's more than a year of deals still processed by hand while the build limps toward launch, during the exact refinancing wave that made speed urgent in the first place. Nobody prices in the tiebreaker question either: who runs this thing after it ships? Model governance, security patching, ongoing CRE-domain QA as policy and document formats drift, none of that shows up in the pitch deck, and all of it needs a name attached to it 18 months out. SOC 2 compliance and institutional memory aren't features you check off once. They're jobs, with salaries attached.

Building looks cheap at the API call. It gets expensive everywhere else, in the corners of the budget nobody wanted to price too closely.

The real cost of buying SaaS when the pricing structure works against you

Buying has its own costs, and pretending otherwise is its own flavor of self-deception. The sticker price on a SaaS contract is rarely the real number; total cost of ownership tends to land at 2.5x to 4x the stated license fee once everything gets counted.

A handful of things quietly eat the savings. Per-seat pricing compounds as the team grows with no matching improvement in what the software does. Vendor lock-in builds as your workflows get woven into their platform, until switching costs turn genuinely prohibitive. Feature gaps persist because the roadmap belongs to the vendor, not you, so you end up bending your process around their product instead of the other way around. Data ownership becomes a headache the day you try to leave, since pulling your own information back out of somebody else's system is rarely fast or clean. And prices climb regardless: vendors have raised rates 10% to 25% a year on average, a steady cost of staying put.

Part of why the custom software market is growing so fast, projected to grow from $53 billion in 2025 to $334 billion by 2034 at a 22.7% compound annual growth rate, is exactly this. Some of that growth is firms who ran the SaaS experiment, hit the lock-in wall at full speed, and decided the long-term math simply didn't work.

Here's the sharper point for CRE specifically. A generic, horizontal tool with a CRE label slapped on the pricing page carries every one of those risks, plus one more: it was never built for document variability at CRE's scale, never built for lending-policy exception logic, never built with audit-readiness baked in from day one. The SaaS buy only pencils out when the vendor's domain expertise earns back that TCO premium. That's the question worth sitting with, rather than treating every vendor as interchangeable in some abstract build-versus-buy debate.

A framework for making the decision based on what actually differentiates your institution

The question isn't whether you want control. Everyone wants control. The real question is whether your underwriting workflow is a genuine competitive moat or a commodity process wearing your firm's parameters like a costume. If it's a moat, meaning proprietary risk models, unique data sources, lending criteria nobody else has encoded, building or heavily customizing makes sense. If it's standard CRE underwriting logic run through your own templates and add-back conventions, buying a domain-specific platform and configuring it to your IP is the sounder path.

A few conditions genuinely push toward building. The workflow is proprietary in fact, not just familiar and comfortable to the people who built it. Data cannot leave your infrastructure under any circumstances, full stop, no exceptions carved out later. Per-seat pricing would punish you economically at your current scale. And, this is the one people skip, the firm can actually staff and sustain model governance, security, and CRE-domain QA as ongoing functions rather than side projects somebody picks up when there's spare time, which there never is.

The case for buying rests on a different set of facts. Time-to-value matters, and that 7-to-14-month build window represents deal volume the platform never touches while it's being written. The team lacks CRE-domain AI expertise in-house and can't realistically hire around that gap fast enough to matter. The workflow needs to evolve with new document types and new regulation faster than an internal team can reasonably ship updates. And security certification, SOC 2, audit trails, is required, with the cost of achieving it independently prohibitive enough to make the decision for you.

There's a variable that almost never makes it into these conversations: analyst opportunity cost. At 20 to 30 minutes of manual data entry per deal, running 10 to 15 offering memorandums a week, an analyst burns 4 to 6 hours weekly on work that produces zero insight. At a fully-loaded salary around $100,000, roughly $50 an hour, that's $10,000 to $15,000 a year per analyst spent typing instead of thinking. A domain-specific platform that removes that cost pays for itself fast. A build that takes 7 to 14 months to ship just extends the waste well past a year before it even starts paying anything back.

One question that ought to kill or approve any build proposal on the spot: can anyone in the room name the specific person who owns model governance, CRE-domain QA, and security patching 18 months from now? If the room goes quiet, that's the answer.

Why domain specificity is the variable that determines whether buying works

Not every SaaS platform carries the same TCO, and not every vendor has actually solved the problems that would otherwise push you toward building. That's the variable deciding whether buying makes sense at all, and it's the one most comparison spreadsheets skip entirely.

A purpose-built CRE underwriting platform has, at least in principle, already absorbed the painful parts on your behalf. Years of exposure to the full range of document formats, from 40-plus T-12 variations to broker-specific OM layouts and rent rolls with no consistent structure whatsoever. Lending-policy logic and exception flagging designed around actual commercial credit workflows, not adapted from something else. Financial spreading that respects a firm's existing templates and add-back conventions instead of forcing everyone into one generic mold. Audit trails and compliance logging built into the process from the start rather than bolted on afterward. Source citations attached to every extracted number, so an underwriter can check the work without hunting back through the original PDF for the figure it came from.

A generic, horizontal AI tool typically offers none of that. It won't have CRE-specific accuracy on document types it wasn't trained on, won't integrate with your firm's existing models and deal history, and won't run covenant monitoring on the same data layer as underwriting, which means separate tools and separate reconciliation work down the line. That last part deserves its own sentence: covenant monitoring, underwriting, and portfolio intelligence work best on one shared data layer, because the covenant set gets defined during underwriting and calculated from the same financial statements using the same spreading and add-back logic. Split that across two tools and you've recreated the exact reconciliation burden you were trying to kill in the first place.

The real question to put to any vendor is whether the platform encodes actual CRE underwriting expertise, or whether it encodes general document processing that you'll still have to configure into CRE workflows yourself, which is just a pricier way of building. Platforms built by people who've closed actual CRE transactions tend to behave differently at the edges than platforms built by technologists who studied CRE from a distance. And the edges are where deals break.

What the portfolio-level implications look like once the platform decision is made

The build-vs-buy decision doesn't stop mattering once underwriting is settled. It determines whether covenant monitoring, risk surfacing, and portfolio intelligence run on that same shared data layer, or whether they require a second system and a reconciliation process nobody budgeted for and everybody resents.

Plenty of lending shops still run covenants through spreadsheets, updated by hand, checked against loan documents by someone toggling between two windows and hoping they don't miss a deadline buried in a footnote. That's the same manual-process risk that made underwriting a bottleneck in the first place, just relocated one step downstream where it's easier to ignore. A platform that treats underwriting and portfolio monitoring as one connected data problem, instead of two separate purchases made six months apart, is what keeps that risk from resurfacing right when the underwriting decision felt finished. The build-vs-buy question doesn't get asked once and settled. It echoes through every system that touches the deal after the credit committee says yes, whether anyone remembers asking it or not.