How Do You Build CRE Software That Scales? Make Underwriting Repeatable

A demo usually starts with one deal. Engineering gets interesting on the second: a different rent roll, fewer unit rows, a revised model, a slow data source, or a document that cannot be read. Those ordinary variations determine whether a product becomes part of the team’s process.

My focus at Cactus is making the path through those variations understandable. The multifamily broker underwriting workflow has explicit stages for documents, property and market evidence, model calculation, audit, and publication. Each stage needs to say what it produced and whether the next stage can safely use it.

AI agents for commercial property acquisitions need a repeatable path from financial data to a reviewable decision. In commercial real estate investment workflow automation, the platform must preserve evidence and calculation identity across each handoff. An acquisitions analyst should be able to investigate a changed result without rebuilding the entire deal history.

How do you handle variability without hiding it?

CRE packages are inconsistent. One property arrives with current unit-level data; another has an old T-12 and a marketing summary. Requiring perfect inputs would exclude useful early analysis. Treating every package as complete would make the outputs misleading.

The workflow therefore distinguishes business gaps from technical failures. Missing market evidence or a missing document can remain a disclosed limitation. An uploaded document that was not successfully read is a different problem: the system needs to stop or resolve it before implying that the analysis considered that evidence.

Why freeze the evidence for each run?

Underwriting is a moving target. Someone uploads a newer rent roll. A market source returns another observation. The model owner updates the workbook. Those changes are useful, but an analysis needs a stable record of which versions it used.

Cactus stores immutable knowledge generations for the property, market context, model contract, and published result. A Deal Room manifest references the evidence for a specific run. Saving the same generation again with the same content is supported; trying to overwrite that generation with different content is rejected.

This is a concrete retry boundary. A repeated save should not silently mutate the original evidence. It is not a promise that every operation in the entire product is automatically retried or that every AI answer will be identical. It gives the team a stable place to investigate what changed.

How do you keep calculations isolated and bounded?

A configured model has declared inputs and outputs. The calculation service acquires a workbook slot, applies the intended values, calculates with a timeout, and reads the requested result cells. Previously written cells that are no longer in the current input set are reset to defaults.

Consider a workbook used for a 100-row rent roll and then an 80-row rent roll. Without clearing unused inputs, the second result could include 20 rows from the previous calculation. Resetting prior writes is a small implementation detail with an obvious financial consequence.

The model gateway also associates results with workbook revisions and input hashes. Publication needs the expected result identity. A response from an older calculation cannot be accepted simply because it contains plausible NOI and value fields.

What do the checks prove, and what remains judgment?

Deterministic checks cover relationships that should hold regardless of how persuasive an agent sounds. Reported income less reported expenses must equal reported NOI. Normalization adjustments must bridge to normalized NOI. Unit-mix counts and valuation ranges need to reconcile to the governed model data.

The workflow gives the analyst a bounded chance to resolve audit issues before selecting a publishable result. Keeping resolution bounded prevents an open-ended loop from becoming the hidden completion policy. A technical error must not become a successful result just because the agent has tried several times.

These checks do not prove an investment thesis. A mathematically consistent model can still use a weak rent-growth assumption. The team must review business uncertainty through source support, assumptions, confidence, sensitivity, and the evidence still needed.

How do you keep the report, share view, and Excel aligned?

The application builds a delivery snapshot from the published underwriting source and the matching persisted workbook revision. That common snapshot supports the report, public share projection, and Excel export. It gives those surfaces a shared financial basis.

Sharing also needs an intentional boundary. The public projection selects the fields intended for the shared report and removes internal identifiers and provider details. A source trail inside the product does not mean that every internal source URL or raw document field should appear in a public link.

The report separates changing an assumption in a finalized model from supplying new documents or a new analyst instruction. The latter creates a new analysis version. That distinction helps a reviewer understand whether they are examining a model adjustment or a new pass through the evidence.

How should a team adopt this as deal volume grows?

Start with representative cases, including the difficult ones. An ordinary acquisition, an incomplete package, an unreadable file, and a model change reveal more than repeating the easiest example. Decide what a reviewer must inspect and what evidence would make an analysis unacceptable.

• Compare extracted values and selected assumptions against the original documents.
• Review model outputs against an agreed financial example and a changed-input case.
• Verify that a disclosed evidence gap remains visible in the final report.
• Check that an unsuccessful calculation or reconciliation cannot produce a successful handoff.
• Assign human ownership for investment decisions and external sharing, even when the automated pipeline completes without a manual gate.

Measure workflow completion with failure reasons, correction effort, time spent reviewing, and whether customers actually use the report and Excel output. Those are useful operating measures to establish with a team; they are not performance results claimed here.

Reliable CRE software makes the next deal easier to understand because the review process stays coherent. Hugo explains the evidence architecture, and Badreddine explains the calculation boundary. Together, those decisions are what let a team grow its use of automation with a clear view of its limits.