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.
- What is the read path out of the system of record? A vendor API with documented endpoints, a nightly database replica, an ODBC connection, or a human exporting spreadsheets. Only the first two survive contact with production. If the answer is the fourth, the pilot is a demo.
- What is the write path back? Most proptech pilots are read-only, which is why they demo well and automate nothing. Automation means writing to the source of truth. Ask who owns that write, what validates it, and what happens on conflict.
- What is the entity resolution strategy? Property management data has the same unit represented three ways across accounting, maintenance, and leasing. Deduplication is a real subsystem, not a data-cleaning task assigned to an intern.
- What is the identity model? Multi-org, multi-property, and role-scoped down to the individual unit. A property manager sees 40 buildings; a resident sees one door. Getting this wrong late means retrofitting authorization through every query.
- Who owns the repo, and can you audit it before launch? Test coverage, OpenAPI spec, deployment scripts. If the answer is “the vendor,” you’ve bought a rental, not an asset.
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
Enter fullscreen mode Exit fullscreen mode
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 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 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
- Auth: OAuth2 or JWT with refresh rotation, and a role model that already accounts for org, property, unit, and resident scopes
- Multi-tenancy: row-level isolation by default; document explicitly why if you’re choosing otherwise
- Legacy read path: documented API or replica access, credentials issued and tested before the contract is signed
- Idempotency: every sync job safe to re-run, every write keyed so retries can’t double-post
- CI/CD: automated tests and migrations running in a pipeline the client can execute themselves
- Test coverage: integration tests against a legacy-shaped fixture, not just unit tests on the happy path
- API docs: OpenAPI spec generated from code, not maintained by hand in a wiki
- Observability: row counts and reconciliation deltas per sync, alerting on drift, because silent data loss is the failure mode here
- Handoff: repo access, runbook, and a documented rollback for every migration
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