Replace the spreadsheet export with a real read path and you can see what the pilot budget left out. The shape Brocoders recommends is change-data-capture or a scheduled pull on read-only credentials into raw, append-only staging tables, then normalization and entity resolution into a canonical model of org, property, unit, lease and resident, exposed behind a versioned OpenAPI layer [14]. Two properties there are doing the work. Raw append-only staging makes a bad transform replayable instead of fatal, and downstream code knows only the canonical model, so a legacy schema change breaks one layer rather than the app [15]. Neither is free. The cost lands in entity resolution, because the same unit appears three ways across accounting, maintenance and leasing, which makes deduplication a subsystem and not a cleanup ticket [11].
The identity model is the other line item that gets pushed to phase two. It is multi-org, multi-property and role-scoped down to the unit: a property manager sees 40 buildings, a resident sees one door, and getting it wrong late means retrofitting authorization through every query [12]. Brocoders' default is row-level isolation with a tenant ID on every table, enforced at the query layer, which it says covers the overwhelming majority of property management workloads; its objection to schema-per-tenant is operational, since that turns each migration into an N-times operation, and database-per-tenant is reserved for a contract or a regulator demanding physical separation [16].
The survey arithmetic is worth doing by hand. Ninety-two percent of commercial real estate firms ran a pilot and 5% hit all their goals [3][4], so roughly one firm in eighteen that started got what it asked for [1]. Adoption at 58% against 8% fully automated processes [1][2] means about one adopter in seven automated anything end to end [2]. And the barrier percentages sum to 203 [3], which tells you the question was multi-select: the 25% naming integration is a count of firms that mentioned it, not a measure of the hours [6].
MIT's 95% is the figure that will get quoted. It is also the one that transfers least. Brocoders cites it as generative AI pilots producing no profit, across industries, measured in August 2025 [5]. To read it as a forecast for a proptech read-integration you would need the denominator to be pilots whose value depended on writing back into a system of record, and nothing in the source says it is. It is a prior on pilots, not a number about this architecture.
Brocoders sells exactly the integration work its postmortem prescribes, which is worth holding in mind; the diagram is still the one I would draw. Where I would push is the checklist. The postmortem says production needs a real read path, an auth boundary, an audit trail and a write path, and that pilots ship with none of the four [8], but the five questions it tells you to ask cover read path, write path, entity resolution, identity and repo ownership [9][10][11][12][13]. The audit trail is named as a requirement and then absent from the gate. Given that the write path is deliberately deferred behind a reconciliation job that compares canonical state against the legacy source before anything is pushed back [17], the audit trail is the thing you will need first, because it is what makes the reconciliation argument settleable.
