Most real estate companies should buy far more technology than they build. The harder decision is knowing where standard software should stop. This article presents a three-path framework: buy common capabilities that provide parity, configure and integrate platforms where value comes from fit and information flow, and build selectively where proprietary data, institutional knowledge, workflow, or decision logic can create economic advantage. The framework rejects both extremes. Custom software is not inherently superior, and off-the-shelf software is not always the best answer. The right decision depends on where competitive value actually resides, what the capability is worth, and whether that value justifies the continuing cost and responsibility of ownership.
Most real estate companies should buy far more technology than they build. The difficult question is knowing what not to buy.
A capable general ledger is essential. So are reliable communications, security, standard customer relationship management, and many common productivity capabilities. Established products can usually deliver those functions faster, more economically, and with less implementation risk than proprietary development. Rebuilding what the market already provides requires a very specific justification.
The more interesting question is where the firm actually creates advantage. What does the organization know how to do particularly well? Which decisions depend on institutional knowledge, proprietary data, relationships, or operating judgment that a standard product cannot fully express? Those are the places where the sourcing decision becomes strategic.
When parity is enough
Path 02When value comes from fit and information flow
Path 03When the advantage justifies ownership
Buy the baseline
The first path is to buy common capability when parity is enough. In commercial real estate, that may include core accounting, standard CRM functionality, common communications, security, productivity tools, document utilities, and other capabilities where differentiation does not come from owning the software.
The objective is not merely convenience. Buying proven capability can reduce implementation time, spread development and security costs across a larger customer base, and provide mature functionality that would be expensive to reproduce internally.
The ceiling is straightforward: competitors can usually buy the same capability. That is not a reason to reject it. It is a reason to evaluate the investment as a baseline capability rather than as a source of competitive advantage.
The operating rule is simple: do not rebuild what the market already provides economically unless there is a compelling reason to own it.
Configure and integrate the business
The second path is to keep proven platforms but make them fit the way the business actually operates. This is where configuration and integration become strategically important.
A real estate company may have capable systems for property management, accounting, leasing, customer relationship management, asset management, documents, and market data, yet still struggle because information does not move cleanly across them. Employees re-enter data, maintain shadow spreadsheets, reconcile conflicting versions, or wait for information that exists elsewhere in the organization.
That can look like a need for a new platform when the real problem is the operating layer between systems. Connecting data, defining handoffs, embedding company-specific rules, and putting the right information in front of the right person may create more value than replacing another application.
This middle path matters because effectiveness often comes from orchestration rather than ownership. The platform may be standard, but the way systems, data, and workflows are connected can reflect how the organization actually creates value.
Build the advantage
The third path is to build selectively where a proprietary capability can create enough economic value to justify owning and maintaining it.
In commercial real estate, that might be an underwriting process that combines internal experience with market data, an acquisition-screening capability that identifies opportunities others overlook, a lease-intelligence workflow that interprets unusual restrictions, a capital-allocation process that prioritizes assets differently, or a decision engine that applies institutional judgment consistently across a portfolio.
AI can expand this category, but the same principle applies. An AI capability embedded in an off-the-shelf product is available to every customer of that platform. It may create efficiency or effectiveness, but it does not automatically create differentiation. Alpha comes from how proprietary data, institutional knowledge, decision logic, and workflow are combined and put to work.
The burden of ownership also matters. A custom capability creates responsibilities for security, support, data quality, testing, governance, model behavior, maintenance, and future change. The strategic advantage has to be worth those continuing costs.
Apply it to your portfolioGet a personalized 20-minute evaluation with Mike.
Book a timeThree tests before you build
A build decision should pass three tests.
First, is the capability genuinely differentiating? If competitors can obtain substantially the same result by purchasing the same product, the case for proprietary development is weak.
Second, have the lower-cost alternatives been exhausted? Configuration, integration, workflow redesign, or better use of existing systems may solve the problem without creating another application to own.
Third, does the expected economic value justify ownership? The capability should move a number that matters, such as revenue, margin, risk, cycle time, operating capacity, customer retention, decision quality, or enterprise value, by enough to justify the cost of building and maintaining it.
Calling something proprietary does not make it valuable. The economics still have to work.
How this connects to the Three Levels of Technology Return
I use the Three Levels of Technology Return to frame the economic side of the decision. Efficiency means doing the same work with less time or cost. Effectiveness means producing a materially better outcome. Alpha means creating a capability competitors cannot readily obtain by purchasing the same technology.
The sourcing response should follow the return. Buy common capability when parity is sufficient. Configure and integrate when the value comes from fit, orchestration, and information flow. Build selectively when differentiated capability can create enough economic advantage to justify ownership.
The full economic framework is developed in “The Three Levels of Technology Return: From Efficiency to Alpha.”
The decision to bring into the room
The question I would bring to a technology planning meeting is this: Which important decision does our firm make differently, and what prevents us from applying that judgment consistently?
That question puts the emphasis where it belongs. Not on whether custom software is fashionable, and not on whether an off-the-shelf vendor has released another feature, but on the point where technology can support an operating or financial advantage that matters.
Buy the baseline. Connect the business. Build the advantage.