Сделки с коммерческой недвижимостью в Дубае — из WhatsApp в платформу

Платформа строится вокруг владельцев — именно они создают ликвидность. У популярного объекта могут быть десятки входящих запросов, среди которых много случайных или нерелевантных.

Апрув дает владельцу контроль над процессом: в сделку попадают только те участники, с кем он действительно готов работать.

В CRE отказ часто означает «предложи другие условия». Если владелец не указал причину, платформа подсказывает возможные: цена ниже рыночной, недостаточно информации о покупателе. Это снижает трение и держит переговоры живыми.

Term Sheet, Due Diligence, Contract и Registration давно существуют в CRE как части реального процесса сделки. Моя задача была не придумать новый сценарий, а сделать его управляемым через интерфейс.

Перед Term Sheet обе стороны проходят короткий этап Preparation, где каждая подтверждает начало сделки.

На первый взгляд это выглядит как лишний шаг. На практике — экономит время и деньги. В реальных CRE-сделках критичные вопросы часто выясняются слишком поздно: структура сделки, сроки закрытия, статус объекта или наличие обременений.

Прежде чем делать форму, я разобрал реальные Term Sheet'ы и Contract'ы из дубайских CRE-сделок: какие условия повторяются, что влияет на следующие этапы, где нужна гибкость. Так документ стал не набором инпутов «из головы», а цифровой версией реального переговорного процесса.

Term Sheet — документ, который обе стороны редактируют поочередно. Без системы версионирования возникала классическая проблема: пока одна сторона вносит правки, другая работает с устаревшей версией.

Для решения этого сценария я адаптировал git-подход к версиям и конфликтам. Это решило проблему конфликтов и одновременно создало прозрачную историю переговоров.

После согласования основных деталей начинается Due Diligence — этап проверки документов и объекта перед заключением контракта.

Проблема в том, что в CRE нет универсального набора документов: покупка, аренда и разные типы объектов требуют разного. Поэтому чеклист DD не фиксированный — стороны собирают его индивидуально из шаблонов платформы и кастомных пунктов.

Registration стал единственным этапом, который завершал не пользователь, а модератор. Он вручную проверял смену права собственности через DLD и переводил сделку в статус Completed.

Для MVP мы сознательно отказались от интеграции и закрыли процесс вручную. При этом для пользователя сценарий оставался бесшовным.

Проект остановился не из-за продукта. Изменение инвестиционного климата в регионе повлияло на финансирование, и запуск приостановили.

Несмотря на это, за время работы я прошел полный цикл создания сложного B2B-продукта: от проектирования бизнес-логики и пользовательских сценариев до интерфейсов и системных процессов.