Proptech buying goes wrong in a predictable way: a demo impresses, a contract gets signed, and eighteen months later the tool is half-deployed, barely used, and walled off from every other system in the building. The product itself is rarely to blame — the decision was made on features when it should have been made on fit. This is a process for choosing on fit: the criteria that matter, the questions that expose the gaps, and a scorecard to keep the decision honest.
The short version
Choosing the right proptech solution comes down to five moves:
- define the outcome you’re buying before you look at products
- bring the people who’ll live with the decision into it early
- evaluate against fit criteria, not feature lists — interoperability, data ownership, what the system actually does, security, and proof
- make vendors substantiate their claims;
- and score every option the same way.
The best tool on paper is often the wrong one for your stack.
Start with the outcome, not the product
Before you shortlist anything, write down the specific outcome you’re buying and how you’ll know you got it. Not “we need an energy platform” — “we need to cut peak demand across twelve buildings without adding headcount, and we’ll measure it against the current monthly peak.”
This one step reframes the whole evaluation. A feature list can’t tell you whether a tool delivers an outcome; only a clearly stated outcome can tell you which features actually matter. It also gives you the measure you’ll hold the vendor to later, which is the single most useful thing to establish before anyone starts selling to you.
Bring the right people in early
Proptech decisions get made by one team and inherited by three others. The facilities and operations lead who has to run it day to day, the energy or sustainability manager whose targets depend on it, the asset or portfolio manager funding it, and the technology leader who has to integrate and secure it — each sees a different risk, and each can veto adoption after the fact if they weren’t in the room.
Get their must-haves on the table before the shortlist, not after the contract. A tool that delights one persona and blocks another doesn’t get used.
The criteria that actually matter
Most evaluation checklists are feature inventories. These are fit criteria — the things that determine whether a solution survives contact with your real estate, your existing systems, and your next five years.
1. Interoperability with what you already own
Your buildings already run BMS, meters, sensors, and control systems from a dozen vendors. The right solution works with that estate; the wrong one asks you to replace it. Rip-and-replace is the most expensive, slowest, and riskiest path in proptech, and it’s often disguised as “our platform is the single pane of glass.”
Ask: which of our existing systems does this integrate with out of the box, and what does integrating the rest actually take? Tradeoff to weigh: a closed, single-vendor stack can be faster to stand up on day one — the cost arrives later, as lock-in.
2. Data ownership and an open model
Ask who owns the operational data your buildings generate, and in what form you can get it out. Solutions built on an open, standardized data model — an ontology such as RealEstateCore — let your data mean the same thing across every building and every future tool. Proprietary models trap it in one vendor’s schema, so every new capability has to come from that vendor, on their timeline.
Ask: is our data portable, and is the underlying model open or proprietary? Tradeoff to weigh: proprietary systems sometimes ship polished features sooner; open models protect your optionality as your portfolio and stack evolve.
3. Does it advise, or does it act?
This is the distinction that separates a dashboard from an operating system. Many “AI” products detect, forecast, and recommend — then hand a person a to-do list. Agentic solutions close the loop: they perceive conditions, decide, and act on the building within guardrails, then report back. Both have value, but they solve different problems, and vendors blur the line constantly.
Ask: after your system flags something, does a person still have to act for anything to change? Why it matters: if you’re buying to reduce workload across a portfolio, insight-only tools add work — someone has to act on every alert.
4. Security, governance, and guardrails
Anything that connects to — or acts on — building systems is part of your attack surface and your operational risk. The bar is higher for solutions that take action, not just read data. You want bounded authority, clear escalation, an audit trail of every decision, and compliance with the standards your organization already holds.
Ask: what is this system allowed to do without a human, what happens at the edge of that, and can we see every action it took? Why it matters: “it’s autonomous” is a feature; “here’s exactly what it can and can’t do, and here’s the log” is a governable one.
5. Proof you can actually check
Every vendor claims outcomes. Few can substantiate them. Treat outcome numbers as claims to interrogate, not facts to accept, and ask which tier each one sits in:
- Measured — from a named, comparable deployment, attributable to a real customer.
- Modelled — from a calculation, with the assumptions stated so you can pressure-test them.
- Referenced — from a credible third party, cited.
Ask: is this number measured, modelled, or referenced — and can I speak to the customer it came from? Red flag: a headline percentage with no source, no assumptions, and no reference customer behind it.
6. Scale economics across the portfolio
A tool that works beautifully in one building can collapse under fifty. Ask how effort and cost grow as you add buildings — does each new site need a bespoke integration and its own configuration, or does the same logic deploy across the estate because everything resolves to one model? The answer decides whether this is a point solution or a portfolio capability.
Ask: what does adding the fiftieth building cost in time and money versus the first? Why it matters: per-building integration cost is where proptech business cases quietly die.
7. Vendor viability and roadmap
Proptech is a crowded, consolidating market. You’re not just buying a product; you’re betting on a company being there — and investing — in three years. Look at funding, customer base, integration ecosystem, and whether the roadmap points where the category is heading rather than where it was.
Ask: who’s behind this, who else runs it at our scale, and where does the roadmap go next? Why it matters: an abandoned proptech tool is worse than none — it’s a sunk integration you now have to unwind.
Questions that expose the gaps
Take these into every vendor conversation. The quality of the answers tells you more than the demo:
- Which of our existing systems does this work with today, with no custom development?
- Who owns our data, and can we export it in an open format?
- After the system detects something, does it act, or does it wait for us?
- What can it do autonomously, and where’s the audit trail?
- Is that outcome number measured, modelled, or referenced — and who’s the reference customer?
- What does deploying across our whole portfolio cost versus a single building?
- What happens to us if you’re acquired or change direction?
Vague, deflecting, or “we’ll scope that in the SOW” answers to these are the signal, not the exception.
A simple scorecard
Score every shortlisted solution the same way so the decision rests on evidence, not on who gave the best demo. Weight the criteria by what your outcome demands, rate each vendor 1–5, and multiply.
| Criterion | Weight | Vendor A | Vendor B | Vendor C |
|---|---|---|---|---|
| Fit to the defined outcome | ×3 | |||
| Interoperability with our stack | ×3 | |||
| Open data model / ownership | ×2 | |||
| Acts vs. only advises | ×2 | |||
| Security and guardrails | ×3 | |||
| Substantiated proof | ×2 | |||
| Portfolio scale economics | ×2 | |||
| Vendor viability | ×1 |
The weights are a starting point — raise security if you’re acting on critical systems, raise scale economics if you’re rolling out across a large portfolio. The discipline matters more than the exact numbers: the same questions, scored the same way, for every option.
Common mistakes to avoid
Buying the demo, not the deployment. Demos run on clean, curated data. Ask to see the tool running on messy, multi-vendor, real-world building data — ideally yours.
Optimizing for features over fit. The longest feature list rarely wins. The solution that fits your existing stack, your data, and your team’s actual workflow does.
Ignoring the integration bill. The license fee is often the smaller number. Integration, configuration, and per-building rollout are where the real cost lives — get them quoted up front.
Skipping the people who’ll use it. A tool the operations team won’t adopt is a shelfware line item, no matter how good the technology is.
Accepting outcome claims at face value. If a vendor can’t tell you whether a number is measured, modelled, or referenced, treat it as marketing, not evidence.
Common questions
What’s the single most important factor?
Fit to a clearly defined outcome. Everything else — features, interoperability, price — only means something relative to the specific job you’re buying the tool to do. Define that first and most of the shortlist filters itself.
How do I compare vendors that all claim to do “AI”?
Look past the label to what the system does after it detects something. If a person still has to act on every insight, it’s analytics. If it acts within guardrails and shows you what it did, it’s agentic. They solve different problems — decide which one you actually have.
Should I choose a single all-in-one platform or best-of-breed tools?
It depends on whether the platform is open or closed. An open, standards-based platform can give you the coherence of one system without the lock-in of one vendor. A closed all-in-one trades flexibility for convenience — fine if your needs are narrow and stable, risky if your portfolio and requirements are still evolving.
How do I know if a vendor’s outcome numbers are real?
Ask which tier each number sits in — measured, modelled, or referenced — and ask to speak to the customer behind a measured claim. A vendor who can source their numbers will; one who can’t will change the subject.
ProptechOS is built on the open RealEstateCore ontology, works with the building systems you already own, and turns your system of record into agentic operations rather than another dashboard. AI for real estate, built to act.
