Build versus buy is framed as one decision. It is two. The first is who designs the software: whose rules, whose fields, whose definition of a good deal. The second is who operates it: who hosts it, patches it, upgrades it and answers when it breaks. A CRE firm should almost always own the first. It should rarely own the second. Vendor-operated custom software is the arrangement that separates them: the tool is built to the firm's specification, and someone whose business is running software keeps it running. The firm keeps its edge without inheriting a maintenance department.
Key Takeaways
Build versus buy hides two separate decisions: who owns the logic and who operates the software. They do not need the same answer.
Operating software is the expensive part. Robert Glass put maintenance at 40 to 80 percent of total software cost, and none of that work encodes a firm's edge.
AI systems carry more operating burden than ordinary code. Sculley and colleagues, in a 2015 NeurIPS paper, showed that the model is a small part of a production machine learning system.
A firm should own its specification, its data, its test set and its exit rights. It should hand off hosting, patching, dependency upgrades, model changes and on-call.
Custom software a firm cannot afford to operate well is not an asset. It is a liability with a login screen.
What is the difference between owning software and maintaining it?
Owning software means controlling what it does: the rules it applies, the fields it produces, the data it holds and the right to take all of that elsewhere. Maintaining software means keeping it running: servers, security patches, library upgrades, monitoring and fixes. The first is strategy. The second is operations, and operations is a separate trade with its own economics.
CRE firms blur the two because they arrive together when a firm builds in-house. A developer writes a screening tool, and the firm now owns both its logic and its upkeep. The logic is where the value sits. It is the firm's buy box, its expense normalizations, its view of which lease clauses matter. The upkeep is generic. Patching a web server looks the same at a net lease shop as at a hospital.
The earlier piece on where AI moved the build-versus-buy line argued that AI cut the cost of writing software, not owning it. The corollary: if ownership is the expensive part, the question becomes who is best placed to carry it.
Why is maintenance the part a firm should hand off?
Maintenance is the part to hand off because it is large, recurring, and identical across firms. Robert Glass, in Facts and Fallacies of Software Engineering, put maintenance at 40 to 80 percent of lifetime software cost. That spending buys uptime and safety, not differentiation. Work that creates no edge belongs with whoever does it at the lowest cost.
The economics are scale economics. A team that operates software for many clients monitors one stack, patches one dependency tree and keeps one on-call rotation. A firm operating one tool pays the full fixed cost of that work for a single system.
The cost of neglect is concrete. In December 2021, the Log4Shell vulnerability in the widely used Log4j logging library forced emergency patching across the software industry. The Cybersecurity and Infrastructure Security Agency issued Emergency Directive 22-02 ordering federal civilian agencies to mitigate within days. Every organization running affected code had the same deadline, whether or not it had anyone assigned to meet it.
Neglect also compounds. In a 2020 McKinsey survey of 50 CIOs at large financial-services and technology companies, respondents estimated that tech debt amounted to 20 to 40 percent of the value of their technology estate, and that 10 to 20 percent of budget meant for new products was diverted to it.
Which custom software should a CRE firm not maintain itself?
A firm should not maintain software that depends on things outside its control, needs attention at hours no one is watching, or produces numbers that end up in a lender package or an investment committee memo. The more of these traits a tool has, the stronger the case for someone else operating it.
Trait | Example in CRE | Why self-maintenance fails |
|---|---|---|
Depends on a changing AI model | Lease extraction, OM parsing | Model versions change and outputs shift without warning |
Depends on outside data feeds | Comp retrieval, market rent pulls | Formats and endpoints change; the tool breaks silently |
Holds sensitive documents | Deal data, tenant financials | Security patching is continuous and mandatory |
Feeds decisions with audit exposure | Underwriting inputs, rent roll reconciliation | Errors must be caught and traced, not discovered later |
Built by one person | Any tool from a single analyst or developer | The tool stops evolving when that person leaves |
AI tools score highest on this list. Sculley and colleagues, in Hidden Technical Debt in Machine Learning Systems (NeurIPS 2015), showed that the model code in a real machine learning system is a small fraction of the whole. The rest is data collection, verification, configuration, serving and monitoring, and they warned that such systems incur "massive ongoing maintenance costs."
Tools with none of these traits, such as a spreadsheet macro or a static report, can stay in-house.
"The logic is the asset. The server is a chore. Firms that confuse the two end up maintaining chores and neglecting assets."
What does a vendor-operated custom arrangement need to protect the firm?
It needs four protections: the firm owns its specification, its data, its test set and a clean exit. Without those, vendor-operated custom software turns into ordinary vendor lock-in with a custom label. With them, the firm keeps everything that carries its edge and rents only the labor of keeping it running.
The firm owns | The operator handles |
|---|---|
Written specification of rules, fields and outputs | Hosting, uptime and backups |
All input documents and extracted data, exportable on demand | Security patching and dependency upgrades |
A benchmark test set with known correct answers | Model version changes and regression runs against that test set |
Contract terms on data use and training | Monitoring, incident response and on-call |
Exit rights: data export and transition support | Documentation that lets a successor take over |
The test set is the protection most firms skip. A set of documents with verified answers lets the firm confirm, after every model or code change, that the tool still produces what it did before. That is the discipline described in acceptance testing for AI deployments. Data-use terms matter for the same reason covered in what it means when a vendor trains on your deal flow: operating the tool must not become a license to learn from the firm's pipeline.
How should an operator compare in-house and vendor-operated costs?
Compare annual ownership cost, not build cost, because the build is paid once either way. Add the share of staff time the tool consumes, hosting, and a provision for the developer leaving. That total is the ceiling: any operating fee below it is cheaper, before counting the risk the firm no longer carries.
Worked example: a custom lease extraction tool
The inputs below are illustrative assumptions chosen to show the mechanics, not market prices. A firm has built a custom lease extraction tool. The build cost is sunk and the same under either option, so it drops out of the comparison.
Input (assumed) | In-house | Vendor-operated |
|---|---|---|
Developer fully loaded cost | $180,000 a year | Not applicable |
Share of developer time on the tool | 50 percent | Not applicable |
Annual staff cost | $90,000 | $0 |
Hosting and services | $6,000 a year | Included |
Developer departure provision: one departure in five years, three months of replacement ramp at full cost | $45,000 over five years, $9,000 a year | Operator's risk |
Annual ownership cost | $105,000 | Operating fee |
The in-house figure sets the break-even at $105,000 a year. Any operating fee below that is cheaper on cost alone. At a fee of $50,000 a year, the firm saves $55,000 a year, or $275,000 over five years.
Two costs sit outside the table and both push the same direction. The first is the half of a developer's year that returns to work only the firm can do. The second is the risk transfer: a missed patch or a silent model regression becomes the operator's problem to prevent, measured against the firm's test set.
Frequently Asked Questions
What is vendor-operated custom software?
Vendor-operated custom software is built to one firm's specification but hosted, patched, upgraded and monitored by an outside operator. The firm owns the logic and data. The operator carries the work of keeping the system running.
Is vendor-operated custom software the same as buying off-the-shelf?
No. Off-the-shelf software applies the vendor's logic to every client, which is why packaged tools are built for the median firm. Vendor-operated custom software applies the firm's own logic and outsources only operations.
What should a CRE firm always keep in-house?
A firm should always keep its specification, its data, its benchmark test set and its exit rights. These carry the firm's edge and its bargaining power in any vendor relationship.
When does it make sense for a firm to maintain custom software itself?
Self-maintenance makes sense for small, stable tools with no outside dependencies, no sensitive data and no audit exposure. It also makes sense for firms with an engineering team large enough that no single departure stalls the tool.
Conclusion
The build-versus-buy question asks who writes the software. The better question asks who owns the logic and who carries the upkeep. For a CRE firm, the logic is the investment method made executable, and it should stay in the firm's hands along with its data, its test set and its exit rights. The upkeep is patching, hosting, model changes and on-call, work that looks the same at every firm and gets cheaper with scale. The firm needs to own what makes the software its own, and to stop maintaining what does not.