Share this
by David Stifter on Aug 14, 2026, 3:52:14 PM
Before committing significant internal capital to a build, look seriously at what is already in the market.
A good market scan asks what products exist, how mature they are, how they handle the messy parts, what they cost at real volume, what implementation requires, and where they fail. It should also ask whether the gaps that remain are truly strategic or simply preferences.
Every vendor looks good in a demo. It’s how software is sold. A demo is a controlled environment, built around the vendor’s strongest use cases, populated with cleaner data than most real organizations have, and guided by someone who knows exactly where the sharp edges are.
This is especially important to note in CRE because the data is complex, inconsistent, and highly variable. Leases have unusual structures. Invoices arrive in non-standard formats. Properties have complex ownership arrangements. Client definitions differ. Charts of accounts vary. Legacy systems export data in ways that only a few people understand.
Download our latest eBook for the full guide.
How to Buy Well: Separating Software from an Impressive Demo
The question is not whether edge cases exist. The question is whether the vendor has encountered them, solved them, and built those lessons into the platform.
The most valuable thing a buyer can do is run the platform against their own data, not the vendor’s sample data.
Ask the vendor to show:
- Realistic source documents, not clean demo files
- Edge cases from your actual workflow
- What happens when the model is unsure
- How exceptions are routed
- What audit trail is preserved
- How corrections improve future outputs
- Which integrations are native and which require custom work
- What the implementation team needs from you
- What success looks like after 30, 60, and 90 days
- What happens when business rules change
If the vendor is unwilling to run a proof of concept against real data before the contract is signed, that reluctance is itself a data point.
Red Flags & Green Flags
The questions that matter most are often not on a standard RFP. Ask the vendor to describe the last significant bug or data quality issue that affected clients in production. A vendor worth buying should be able to pass the accountability test and talk honestly about failure, limitation, and the unglamorous realities of production use.
Red flags tend to cluster around a few patterns: Reluctance to test on your real data, inability to speak specifically about exceptions, overstated automation claims without clear exception handling, weak answers on permissions, audit trails, and data separation, a roadmap focused on features but not reliability, security, and data quality.
Green flags are their mirror. A vendor who proactively surfaces the limitations of their platform for your specific use case before you ask is demonstrating a level of honesty that tends to predict a better long-term relationship. References who describe not just what works but how the vendor responded when something did not work are valuable signals. A proof of concept process that the vendor treats as seriously as the sales process suggests a company that understands its product is being evaluated against reality, not against a presentation. And a roadmap that reflects visible investment in the problems that matter most in production, data quality, exception handling, audit trails, and reliability, is a more durable signal than a list of impressive features.
A great vendor does not pretend production is easy. A great vendor shows you how they manage the difficulty.
Making the Buy Decision Stick
A technology buying decision made well and implemented poorly produces outcomes that are hard to distinguish from a bad buying decision.
The platform underperforms. Adoption is lower than expected. The vendor gets blamed. Evaluation usually involves a small group of decision-makers with high context and strong motivation, but the implementation affects a larger group of people who may have had no involvement in the selection. Closing that gap requires communication before implementation begins, not after problems surface.
The implementation often deserves as much scrutiny as the product.
Implementation risk tends to concentrate in predictable areas: the mitigation is more time, more specificity, and more organizational involvement earlier than feels necessary.
That’s why implementation should include the people whose workflows will change most. They know where the process breaks. They know which edge cases matter. They know what will be trusted and what will not.
A strong product meets users where the work already happens. A tool that creates another place to check, reconcile, explain, or manually correct may be technically impressive and still fail operationally. Adoption is trust. And trust comes from accuracy, consistency, speed, fit with workflow, and confidence that exceptions will be handled.
The highest-performing technology organizations are not pure builders or pure buyers. They build quick wins, invest in proprietary edge, buy aggressively where the market has already solved the core, and create governance that lets builders work with the organization rather than around it.
Real estate should do the same.
Read "Your Builders Are Already Building: A CRE Leader's Guide to Build vs. Buy in the AI Era" for a practical framework on how to answer the build vs. buy investment question .