For decades, commercial real estate firms bought software applications and adapted their workflows to fit them. That model created enormous value, but it also assumed that firms performing similar work operated in similar ways. They often do not.
Two investment managers, lenders, brokerage firms, or valuation practices may use entirely different data sources, approval processes, risk frameworks, analytical procedures, and reporting standards. Even within the same company, workflows may vary by market, property type, client, transaction, or assignment. Standard software can handle the common elements of these processes, but the difficulty appears in the exceptions, judgment calls, handoffs, internal controls, and specialized analyses that distinguish how one organization actually operates from how another does.
The next generation of CRE software will not force all of those workflows into the same application. It will standardize the infrastructure beneath them and allow the workflows themselves to be engineered around how each organization works.
From Software Products to Engineered Workflows
The traditional commercial software product begins with a generalized view of the market. A developer identifies what many users have in common and builds a product around those shared requirements. The customer receives a predefined data model, interface, calculation structure, and sequence of tasks.
A workflow-centered model begins somewhere else. It starts with the organization itself: how information enters the business, where it is stored, who reviews it, which calculations are standardized, where professional judgment is required, what needs to be documented, which exceptions require escalation, and what information should move to another team, system, or report. The software is then shaped around that operating reality.
This does not mean every firm should build its own technology stack from scratch. More likely, firms will begin with developed infrastructure that provides the difficult foundational components, including databases, permissions, integrations, document storage, audit history, calculation services, security, and system reliability. The specialized operating workflow can then be engineered on top of that foundation.
The distinction matters. The future is not unlimited customization. It is dependable shared infrastructure combined with workflows that reflect the legitimate differences among organizations.
Why the Economics Are Changing
Custom software is not new. Large companies have built internal systems for decades. What is changing is the speed, cost, and practicality of development.
Cloud infrastructure has reduced the need to build foundational systems from the ground up. APIs make it easier to connect data sources and specialized services. Reusable components have shortened development cycles, while artificial intelligence is accelerating prototyping, code generation, testing, documentation, and interface development.
These changes do not make engineering discipline less important. Production systems still require sound architecture, governance, security, testing, and maintenance. A prototype that works in a demonstration is not the same as a reliable operating system. What has changed is the cost of building the final layer between general infrastructure and a company’s actual process. That layer is becoming faster and less expensive to create, and it is often where much of the practical value resides.
Forward-deployed engineering is one expression of this shift: technical teams working directly with domain experts to build systems around real operating processes rather than abstract market requirements. Software development is moving closer to the work itself.
CRE Is a Workflow and Judgment Problem
Commercial real estate is often described as a data problem. That is true, but incomplete. Information is fragmented across spreadsheets, documents, third-party databases, accounting platforms, property systems, emails, and individual employees. Definitions are inconsistent, historical records may be incomplete, and important assumptions are often embedded in files with limited visibility or control.
Data alone, however, does not produce decisions. A rent roll, sale comparable, lease abstract, market report, expense history, or valuation model becomes useful only when it enters a process. Someone must evaluate its relevance, assess its reliability, normalize it, compare it with other evidence, and determine how it affects the analysis.
Consider acquisition underwriting. One firm may require standardized base, downside, and upside cases. Another may organize its analysis around debt structure and covenant risk. A third may require environmental, zoning, and lease-risk reviews before financial approval. The underlying property data, document controls, calculation services, permissions, and audit history can remain consistent. The operating workflow should not have to be identical.
That is why CRE is not merely a data problem. It is a workflow and judgment problem. The challenge is not simply to automate calculations, but to support a sequence of decisions while preserving the context behind them. A useful system must distinguish among source data, assumptions, calculations, judgments, approvals, and conclusions. It must improve efficiency without obscuring how a result was reached.
The best CRE systems of the future will not merely calculate faster. They will make analytical work clearer, more traceable, and easier to govern.
Standardize the Foundation, Not Every Decision
The argument for adaptable workflows should not be confused with an argument for encoding every user preference into software. Unlimited customization produces brittle systems, while poorly designed automation can preserve inefficient processes rather than improve them. The objective is to identify which elements should be standardized and which genuinely require specialization.
Core infrastructure should generally remain stable. Data definitions, access controls, audit history, document management, integrations, calculation logic, and system architecture all benefit from consistency and scale. The operating layer can be more adaptable because different firms may legitimately require different review sequences, dashboards, reports, approval rules, and analytical procedures. Those differences often reflect real variations in investment strategy, client service, risk tolerance, or professional practice.
Many CRE firms are already developing internal tools through software teams, data scientists, automation platforms, and AI-assisted development. That experimentation is valuable. The lesson is not that firms should avoid internal development. It is that they should focus their development effort on the operating layer where their expertise creates differentiation, rather than rebuilding permissions, audit history, document storage, security, and integration infrastructure from scratch.
The emerging model is therefore not simply “buy” or “build.” It combines both. Firms rely on dependable domain infrastructure and then engineer the specialized workflows that reflect how they operate.
Domain Expertise Becomes More Important
As software becomes easier to create, defining the problem correctly becomes more important. A developer may observe an analyst transferring information from one spreadsheet to another and conclude that the task should be automated. A domain expert may recognize that the transfer includes an implicit review, a classification decision, or a judgment about the reliability of the source.
Automating the visible action without understanding its purpose may remove an important control. The people best positioned to build the next generation of CRE systems will understand both sides of the problem. They will know enough about technology to design reliable systems and enough about the domain to recognize where standardization is appropriate, where judgment is essential, and where automation may introduce risk.
The greatest leverage will accrue to professionals who can translate domain expertise into reliable systems without confusing automation with judgment.
Workflow as Organizational Intellectual Property
Standardized applications are not going away. Many processes are common enough that a well-designed product remains the most sensible solution. But the application may no longer be the final destination. It may become one component within a broader operating environment in which data moves across systems, analytical services are shared, interfaces are created for particular teams, and human review remains embedded where judgment and accountability are required.
As development becomes more accessible, simply possessing software will become less differentiating. The advantage will shift toward how effectively a firm translates its knowledge, judgment, and controls into a repeatable operating system. Workflow is not merely administrative. It is part of the organization’s intellectual property.
The next generation of CRE technology will combine dependable shared infrastructure with specialized workflows grounded in the realities of the domain.