Why 92% of Proptech AI Pilots Never Reach Production (An Engineering Postmortem)

An engineering postmortem by Brocoders reveals that 92% of proptech AI pilots never reach production, citing change management, integration, and data leaks as primary barriers. The article advocates for read-side integration first, using a read replica and projection layer to bridge legacy systems, as demonstrated in Brocoders' work with C.I.A. Services.

A pilot that reads from a CSV export and a production system that reads from a 1998 property management database are not the same project. They share a UI. They share nothing else. That distinction explains most of what happened in proptech this year. AI adoption among property management companies jumped from 20% to 58%. Fully automated processes: 8%. In commercial real estate, 92% of firms ran an AI pilot and 5% hit all their goals. MIT put out a report in August 2025 saying 95% of generative AI pilots produced no profit at all. Read those numbers as an engineer and the story stops being about models. Pilots run against clean, hand-prepared data in a sandbox with no auth boundary, no audit trail, and no write path back into the system of record. Production needs all four. Nobody scoped the four. Where the pilot-to-production gap actually opens The survey answers line up with what you'd guess from a system diagram. 76% name change management and training as the primary barrier, 25% cite integration, 25% budget, 28% legacy system limitations, and 49% report data leaks from missing information. That last one deserves a second look. "Data leaks from missing information" is survey language for a broken contract: the new tool expects a field the source system never populated, so records fall out of the pipeline silently. It's a nullable column nobody modeled. It shows up as a business problem six months after it started as a schema problem. 73% of proptech tools need to connect to something that already exists. So integration isn't a phase of the project. It is the project. The five technical questions to answer before signing anything Not a maturity model. Just the five that predict whether the thing ships. A pattern that survives legacy: read-side integration first The lowest-risk architecture for proptech built on top of decade-old systems is not a migration. It's a read replica plus a projection layer, with writes deferred to phase two. Legacy PM system source of truth │ ▼ CDC / scheduled pull read-only credentials Staging tables raw, untransformed, append-only │ ▼ normalization + entity resolution Canonical model: org → property → unit → lease → resident │ ▼ API layer versioned, OpenAPI-documented │ ├── new web app └── AI / automation workers Two things make this work. The staging tables stay raw and append-only, so a bad transform is replayable instead of fatal. And the canonical model is the only thing downstream code knows about, so when the legacy schema changes, one layer breaks instead of the whole app. On the multi-tenancy question underneath it: row-level isolation with a tenant ID on every table, enforced at the query layer, handles the overwhelming majority of property management workloads. Schema-per-tenant looks safer and turns every migration into an N-times operation. Reach for DB-per-tenant only when a contract or a regulator requires physical separation. The write path comes later, gated behind an explicit reconciliation job that compares canonical state against the legacy source before anything is pushed back. Slower. Also the reason the project is still running in year two. What this looks like when it works Brocoders https://brocoders.com built a hybrid web app for C.I.A. Services, an HOA management company running 30 years of accumulated systems across 150 associations and roughly 50,000 properties. The system pulls live data from their existing property management stack. No infrastructure replacement, no migration cutover, no big-bang rewrite. The legacy system stays the source of truth and the new app reads from it. CondoGenie went the other direction, built from scratch, with structured data integration treated as a first-class concern from the first schema design rather than bolted on after launch. Different starting points, same principle: the integration boundary is designed before the feature list. Our stack for this work is React, Node.js, and TypeScript, with our own DevOps rather than outsourced infra, and bcboilerplates.com https://bcboilerplates.com handling the boilerplate decisions so the early sprints go into the domain model instead of auth scaffolding. Engineering checklist before you fund a proptech build One more number worth sitting with 78% of property managers still verify rental applications manually, while 56% report application fraud in the past year. Automated document verification has existed for years. The technology isn't the constraint. Nobody wired it into the workflow people actually use. That's the whole 2026 story in one line. The models are fine. The plumbing is the work. If you're scoping a build where the hard part is integration with systems you can't replace, that's the conversation worth having early rather than after the pilot stalls. brocoders.com https://brocoders.com