Off-the-shelf software is usually the right starting point. It is faster to deploy, easier to support, and often less expensive than building proprietary technology. The limit is not reached when users become frustrated or a platform lacks a preferred feature. It is reached when the economic, operating, or strategic cost of accommodating the product becomes greater than the value of standardization. At that point, leadership should stop asking only, “Can we configure this?” and ask a broader question: What is the most economically rational way to support this capability going forward?
Most companies should buy far more technology than they build. Standard accounting, CRM, document, collaboration, and property management platforms can provide functionality that would be expensive and unnecessary to recreate, along with security, scalability, upgrades, and support.
But standardization has a cost of its own. Software designed for thousands of customers must reflect common requirements. As an organization’s needs become more specific, the gap between the product and the way the business actually operates can grow. Configuration can close part of that gap. Integration can close more. Workarounds can cover what remains, at least for a while.
The limit is economic, not emotional
Users disliking a system is not sufficient reason to replace it. Neither is a long list of enhancement requests. The more important question is whether the organization is still receiving enough value from standardization to justify the cost of accommodating the software.
That cost typically appears in three places: economic friction, operating friction, and strategic constraint. The categories are related, but they answer different questions: What is the accommodation costing us? What is it doing to the way the business operates? And what valuable capability is it preventing us from creating?
The workaround has become expensive
The software license is rarely the full cost of a system. Organizations may also be paying for consultants, integrations, manual reconciliation, duplicate entry, report preparation, spreadsheet maintenance, exception processing, and employees who spend significant portions of their time configuring output or moving information between systems.
Some of those costs are justified. No enterprise platform eliminates every manual activity, and integration is a normal part of operating a technology environment. The warning sign appears when these activities become permanent operating expenses. A process that requires three systems, two spreadsheets, repeated reconciliation, and recurring consultant intervention may technically work without remaining economically rational.
Leadership should look beyond the license and quantify the labor, integration, consulting, reconciliation, errors, delays, and rework created by the gap. The relevant comparison is the total cost of continuing to accommodate the existing solution versus the total cost and value of the alternatives.
The software begins shaping the business
The second limit appears when employees reorganize the way they work around the software rather than the software supporting the way the business needs to operate.
This often becomes visible through shadow processes. Employees create spreadsheets because they cannot see the information they need, re-enter data because systems do not communicate, or move exceptions through email because the formal workflow cannot accommodate them. Managers wait for information that already exists, and decisions are made without information that should have been available.
None of those conditions individually or automatically justifies replacing a platform. The first response may still be better configuration, integration, data architecture, or workflow design. A disconnected workflow can make a good platform look inadequate, and fixing the connection may be enough. But when the business continuously routes around the platform, the question changes from “How else can we configure this?” to “Is this still the right operating model?”
The software prevents the business from applying what makes it different
The third limit is often the least visible. A standard platform may perform its intended function perfectly and still constrain an organization strategically.
This happens when proprietary data, institutional knowledge, decision logic, customer experience, or operating expertise cannot be expressed within the available product. A real estate company may have a distinctive way to evaluate acquisitions, identify lease risk, prioritize capital, or recognize operating exceptions. The advantage may reside in the judgment itself, not in the software.
If the standard platform cannot consistently apply that judgment, leadership has to decide whether the capability matters enough to warrant something different. That may be a proprietary layer that connects existing systems and applies company-specific decision logic, or a narrowly designed workflow rather than another enterprise platform.
The strategic question is whether the organization is adapting a standardized process or trying to express something genuinely distinctive about how it competes. Proprietary software is not inherently valuable. Proprietary knowledge and capability can be.
Apply it to your portfolioGet a personalized 20-minute evaluation with Mike.
Book a timeConfiguration should have an economic stopping point
Because a product can technically be configured does not mean it should continue to be configured. Every additional rule, customization, integration, exception path, and workaround adds complexity, testing, upgrade risk, support effort, or dependence on specialized knowledge.
There is no universal threshold at which configuration becomes too much. The stopping point is firm-specific and economic. Reaching it also does not automatically justify custom development. The response may be to retain the product, configure it differently, integrate around it, replace it with another standard product, or selectively build a missing capability.
The right answer depends on the economics and which capabilities the business is trying to leverage. The objective is to choose the least complicated intervention that produces the required economic and operating result.
The real question is what the compromise is costing
Technology decisions often become distorted because the visible cost is easy to identify and the embedded cost is not. The software invoice is obvious. Employee workarounds may be spread across departments and budgets. Delayed information may never be labeled as a technology expense, and a missed opportunity may not appear anywhere.
Before approving another customization, integration, point solution, replacement platform, or custom build, leadership should understand the problem being solved, the current workaround cost, the business outcome that should improve, whether existing technology can reasonably deliver that outcome, and whether the economic value justifies owning something different. The question is whether the operating cost of accommodating the software, together with the potential loss of alpha, now exceeds the benefits of maintaining the status quo.
If it does, configuration may no longer be enough. That is when the build-versus-buy conversation should begin.
This article covers the diagnostic step in the broader framework for commercial real estate technology decisions.