PropTech: скорость разработки в real estate SaaS
PropTech-команда, с которой я работал в прошлом году, отгружает 4,2 деплоя в неделю по флагманскому продукту. Их CEO сравнивает это с бенчмарком по SaaS-портфелю и делает вывод: "средненько". Неправда. Финтех с похожим штатом даёт 7,1; чистый B2B SaaS — 9,4. PropTech живёт на пересечении регулируемых данных, геопространственной сложности и MLS-интеграций из 90-х — и сырое число деплоев скрывает, с чем реально борется инженерная команда.
Stack Overflow Developer Survey 2024 помещает real-estate software в нижнюю треть по отчётной скорости сборки и интеграционных тестов. DevEx-бенчмарки Microsoft Research 2024 показывают, что регулируемые отрасли теряют в среднем 23% инженерного throughput только на compliance friction. PropTech накладывает сверху геопространственную сложность.
{/* truncate */}
Чем инженерия в PropTech отличается
Real-estate софт трогает десяток источников данных, которых ни одна другая отрасль не собирает в одном продукте: MLS-фиды со своими XML-диалектами, API с ипотечными ставками, GIS-тайлы карт, базы налогов округов, CRM, e-sign вендоры и часто 20-летняя on-prem система брокерского дома. У каждой интеграции свой SLA, своя compliance-позиция и своя каденция обновлений "свяжитесь с partner manager".
| Ограничение | Что требует | Где бьёт по инженерии |
|---|---|---|
| RESO Data Dictionary | Нормализовать поля MLS через 600+ систем в США | Каждый новый рынок — недели на schema mapping |
| Fair Housing / disparate-impact | Аудит ML-ранжирования, персонализации | Model governance, дополнительные QA-ворота |
| Законы штатов по e-sign | Notarization-воркфлоу различаются по штатам | Feature-flag'и на каждую юрисдикцию |
| Ипотечные данные (GLBA) | Защищённый пайплайн для borrower PII | Отдельная ingestion, шифрование, data-loc |
| Геоточность (границы участков) | Слои карт по county recorder | Тайлы, инвалидация кеша |
| Фото / 3D-туры | Мульти-гиг ассеты на листинг | CDN cost, pre-signed URLs, copyright |
Добавьте мобильное приложение, портал агента, портал покупателя и внутреннюю CMS — типовой surface PropTech-продукта — и один пользовательский flow пересекает 5 из этих ограничений.
Метрики, которые важны в PropTech
1. Integration test pass rate — реальная прокси-метрика velocity
Unit-тесты говорят, что ваш код работает. Integration-тесты говорят, что 14 внешних зависимостей всё ещё того вида, который вы ожидали.
Целевой бенчмарк: ≥ 92% pass на main, замер ежедневно. PropTech-команды ниже 85% стабильно не укладываются в спринты, потому что flaky MLS-тесты перезапускаются и маскируют реальные регрессии.
Почему self-report не работает: разработчики регулярно помечают flake как "known issue" и фильтруют. Настоящий pass rate — это то, что показывает ночной full-suite, а не то, что видно в PR checks.
2. Lead time фичи до юрисдикции
Фича не сделана на merge. Она сделана, когда включена на всех обещанных рынках. PropTech-команда, которая меряет merge-to-deploy, получает приятное число. Замер merge-to-enabled-in-all-promised-markets часто добавляет 2-6 недель на фичу.
Таргет: мерить оба. Разрыв между ними — это legal/ops-налог, а не code-налог.
3. Map render p99
Если в продукте есть карта — карта и есть продукт. Время p99 выше 1,8 секунды предсказывает отток пользователей надёжнее любой другой perf-метрики.
Таргет: < 1,2 с p99 на основной поверхности с картой.
4. MLS sync lag
Часы между изменением листинга в source MLS и появлением в вашей системе. Агенты замечают 2-часовую задержку. Покупатели — 30-минутную. Средний по индустрии — 90 минут; топовые команды сидят на 15-30.
Таргет: < 30 мин p95 для горячих рынков, < 2 ч p95 для хвостовых.
5. Пропускная способность фото-пайплайна
Сколько новых наборов фотографий в час обрабатывает пайплайн. Весной в Северной Америке эта метрика прыгает в 4-6 раз. Команды, не планирующие capacity, обнаруживают это как инцидент, а не как пункт roadmap.
Реальная интеграционная поверхность PropTech-команды. Каждая линия — контракт, который вам не принадлежит.
Как регуляция и масштаб меняют измерение
Fair Housing и правила disparate-impact означают, что любая ML-фича, ранжирующая листинги, агентов или покупателей, требует audit log входов и выходов на 2-7 лет в зависимости от юрисдикции. Это не фича, которую прикручивают после; это решение по архитектуре данных, принимаемое до первого ML-эксперимента.
GLBA меняет staging данных. Всё, что трогает ипотечный borrower PII, не может жить в одном warehouse с данными листингов без дополнительных контролей. PropTech-команда, обращающаяся со всеми данными как с одним пулом, провалит первый CISO review от enterprise-брокера.
Практическое следствие: PropTech-команде нужно на 25-35% больше platform-инженерии, чем сопоставимому B2B SaaS, только чтобы поддерживать compliance-субстрат. Бенчмарки штата из LinearB и аналогов этого не учитывают.
Типовой профиль PropTech-команды
| Параметр | Типичный диапазон |
|---|---|
| Размер команды | 15-40 инженеров |
| Стек | TypeScript на фронте, Python/Go/Java на бэке, PostGIS для гео, Elasticsearch для поиска |
| Каденция деплоев | 3-6/неделю на сервис (11-18 сервисов типично) |
| Основное давление | Свежесть данных + регуляция |
| Toolchain | Множество MLS через RESO Web API, Mapbox или альтернативы, Plaid для финданных, Twilio/SendGrid |
| DORA-позиция | Lead time 3-8 дней; deploy freq 3-6/нед; MTTR 2-6ч; CFR 10-18% |
DORA State of DevOps 2024 показывает медианы по отраслям — real estate попал в "medium" по delivery и в "low" по operational stability. Этот сплит специфичен для PropTech: скорость деплоев нормальная; ломаются интеграции.
Что замерять иначе, чем в стандартном SaaS
- Uptime внешних зависимостей. Относитесь к каждому MLS и внешнему API как к зависимости со своим SLA. PropTech-команда без dependency-дашборда летит вслепую — когда падает MLS штата, вы должны знать раньше саппорта.
- Feature flags с привязкой к юрисдикции. Флаг по штату, по MLS, по типу лицензии. Обычная система флагов схлопывается — нужны иерархические флаги или получите сотни булевских.
- Map rendering как отдельная метрика. Отдельно от API p99. Тайлы, кластеризация, поиск в bounds — свои perf-домены.
- Глубина очереди фото-пайплайна. Alert-worthy, когда backlog превышает 2 часа входящего объёма.
Типичные ошибки
- Считать MLS-данные источником истины. Не являются. У MLS бывают outages, изменения схемы без уведомления, задержанные корректировки. Ваша система должна обрабатывать "листинг был активен вчера, сегодня пропал без события delete".
- Оптимизировать под национальный velocity, когда клиенты локальные. Топ-10 брокеру в его метрополии важно качество данных его метрополии, а не ваш глобальный uptime. SLO по рынкам имеют значение.
- Пропускать разговор про data residency рано. Enterprise-брокеры спрашивают про data residency в первом security questionnaire. Докрутить residency после запуска дорого. Команды в EU-рынках также ловят GDPR + локальные реестры недвижимости со своими ограничениями.
- Считать, что surface агента и surface покупателя делят roadmap. Нет. Агенты живут в продукте 6+ часов в день. Покупатели заходят 3 раза до сделки. Общий код ок; общие приоритеты — ловушка.
Где вписывается PanDev Metrics
Инженерные лидеры PropTech и так управляют кучей разных метрик. PanDev Metrics встраивается как единая картина реального времени разработчиков по сервисам, которые типично крутятся в PropTech-организации — ingestion листингов, map-сервис, портал агента, приложение покупателя. Командам на GitLab on-prem (частый выбор в регулируемых рынках) on-prem Docker-развёртывание работает рядом с внутренней инфраструктурой, не экспортируя исходники. IDE heartbeat-подход отвечает на самый раздражающий вопрос PropTech-инженерии: "кто реально работает над Q2 MLS-экспансией, а кто — над редизайном консьюмер-части?"
Одно правило Git, делающее весь tracking в PropTech рабочим: называйте ветки с task ID (например, feature/MLS-2187). Coding time на инициативу, lead time на юрисдикцию, cost per new market — всё выводится из одного правила именования.
Читать дальше
- Инженерные метрики в финтехе: compliance, скорость и безопасность
- DORA Metrics: полный гайд для инженерных лидеров (2026)
- E-commerce: ускоряем доставку фич перед высоким сезоном
Честное ограничение PropTech: наш датасет B2B-heavy и смещён к англоязычным рынкам. Паттерны выше хорошо подходят США, Канаде, Великобритании и Австралии. LATAM PropTech работает под нотариальными режимами, которые значимо меняют модель данных; сильного сигнала там у нас нет. Если вы строите на рынке с другим реестром недвижимости — это стартовая точка, а не карта.