Как я собрал маркетплейс недвижимости за 3 недели и 300 000 ₽

Марат — владелец компании в недвижимости в Подмосковье. У него работает команда агентов и партнёрская сеть: независимые риелторы и небольшие агентства, которые приводят объекты.

Задача, с которой он ко мне пришёл, на первый взгляд выглядела как «нужен сайт». На второй оказалось сложнее.

Циан и Авито закрывали часть потребности — туда можно выкладывать объекты и получать звонки. Но у этих платформ есть два ограничения, из-за которых бизнес упирался в потолок.

Первое — комиссия и правила площадки. Любое изменение в тарифах Циана напрямую бьёт по марже. Любое изменение в алгоритме выдачи — по количеству лидов. Бизнес, который зависит от чужой платформы, — это не бизнес, это арендатор.

Второе, более важное — у партнёров нет собственного интерфейса. Когда партнёрское агентство хочет выставить 20 объектов, оно либо делает это через аккаунт Марата (и тогда контроль качества ложится на его команду вручную), либо через свой аккаунт на Циане (и тогда лиды идут мимо клиента). Ни один из вариантов не масштабируется.

Клиенту нужна была собственная платформа, где:

• покупатели ищут объекты с нормальной фильтрацией
• партнёры самостоятельно вносят объекты через свой кабинет
• модерация идёт централизованно, с контролем качества
• данные синхронизируются с существующей CRM на 1C Bitrix, которую команда уже год как использовала и не собиралась менять

Цифры, на которые мы договорились: 3 недели работы, фиксированная цена 300 000 ₽, без почасовок и без «плюс-минус».

Первый вопрос, который я себе задаю на любом проекте: а можно ли это сделать на конструкторе? Если можно — надо делать на конструкторе. Это быстрее, дешевле и безопаснее для клиента.

Здесь — нельзя. И вот почему.

Tilda и похожие конструкторы отлично справляются с лендингами и простыми каталогами. Они ломаются на трёх вещах:

1. Роли пользователей. На Tilda нет полноценной системы ролей «покупатель / партнёр / админ» с разными интерфейсами и разными правами. Есть плагины, но они не закрывают кейсы вроде «партнёр видит только свои объекты и только в определённых статусах».
2. Модерация как отдельный процесс. Очередь модерации с состояниями «на проверке / принято / отклонено с комментарием / на доработке» — это не страница и не форма. Это workflow. Конструкторы не проектируются под workflow.
3. Интеграция с 1C Bitrix. Tilda умеет отправлять формы через вебхуки, но не умеет поддерживать двустороннюю синхронизацию с полноценной CRM. А здесь требовалась именно она: объект, созданный партнёром на сайте, должен появляться в CRM; статус объекта из CRM должен отражаться на сайте.

Готовые маркетплейс-движки (вроде CS-Cart или Sharetribe) тоже не подходили — их нужно серьёзно кастомизировать под специфику недвижимости, и к концу работы получаешь франкенштейна, который сложно поддерживать.

Вывод был простой: дешевле собрать свой стек, чем бороться с ограничениями чужого.

Стек получился такой: Next.js 16 на фронте и для серверной логики, PostgreSQL как основное хранилище, собственная JWT-авторизация с ролями, деплой на VPS. Без Supabase и без Firebase — для 1C-интеграции нужен был полный контроль над серверной частью.

Теперь три места, где пришлось думать дольше всего.

Первое — партнёрский кабинет и очередь модерации. Партнёр заходит в свой кабинет, видит свои объекты, может добавлять новые через ту же форму, что и админ (50+ полей, геопривязка, множественная загрузка фото). Но после сохранения объект попадает не в каталог, а в очередь. У админа — отдельный интерфейс модерации: входящие, принятые за сегодня, отклонённые с комментарием. Подтверждение одним кликом — объект улетает в каталог, партнёру приходит уведомление.

Технически это не сложнее CRUD, но архитектурно важно: статус объекта — это отдельное поле, а не «есть объект или нет». Мы заложили это с самого начала, потому что переделка системы статусов в живом проекте — это две недели работы минимум.

Второе — интеграция с 1C Bitrix без простоя CRM. Это была самая рискованная часть. У команды клиента в Bitrix за год накопились объекты, клиенты, история сделок. Останавливать CRM было нельзя ни на день.

Подход был такой: развернули промежуточный слой синхронизации, который забирает данные из Bitrix по REST API, маппит их в схему PostgreSQL и наоборот. Первый прогон сделали в ночь выходного — залили текущие объекты в новую базу без изменений на стороне Bitrix. После этого включили двустороннюю синхронизацию: новое в PostgreSQL → уходит в Bitrix, новое в Bitrix → приходит в PostgreSQL. Если в синхронизации возникает конфликт — приоритет у Bitrix, как у системы, где команда уже работает.

Три подводных камня, которые встретили:

• -несовпадение типов данных (в Bitrix «цена» — строка, в PostgreSQL — numeric)
• дубли объектов при параллельной правке
• таймауты REST API Bitrix на больших выборках — пришлось переходить на пагинированные запросы

Третье — 50+ фильтров каталога с серверной пагинацией. В недвижимости фильтров много: тип, район, цена, площадь, этаж, год постройки, ремонт, удалённость от метро, инфраструктура, тип сделки, и ещё тридцать. Всё это должно работать быстро — иначе покупатель уходит.

Клиентская фильтрация здесь не вариант, потому что каталог растёт и скоро не влезет в память браузера. Поэтому всё на сервере: запросы к PostgreSQL с индексами на основных полях, серверная пагинация, SSR для первой страницы (чтобы Google и Яндекс индексировали категории). Загрузка первой страницы каталога — меньше секунды даже на заполненной базе.

• Срок:3 недели от первого звонка до запуска
• Цена: 300 000 ₽ фиксированно, без доплат
• Роли пользователей: 3 (покупатель / партнёр / админ)
• Функций в админке: 50+
• Фильтров в каталоге: 50+
• Интеграция: 1C Bitrix API, двусторонняя синхронизация, ноль простоя CRM
• Первая загрузка каталога: меньше 1 секунды
• Phase 2: клиент уже планирует расширение — добавление мобильного приложения для партнёров

Я не из тех разработчиков, которые говорят «всегда делайте кастом». Больше половины задач в малом бизнесе отлично закрывается Tilda, InSales, Bitrix24 или Shopify. Если вы можете — делайте на конструкторе. Экономьте деньги и время.

Кастом оправдан в трёх случаях:

1. У вас есть специфика процесса, которую конструктор не поддерживает. Многоролевые системы, модерация, workflow, сложная бизнес-логика. Если вы не можете описать свой процесс через «страницы и формы» — конструктор не потянет.
2. У вас уже есть работающая инфраструктура, с которой нужно интегрироваться. CRM, склад, 1C, внутренние системы. Конструкторы предлагают только поверхностные интеграции — а когда нужна двусторонняя синхронизация в реальном времени, начинаются костыли.
3. Вы строите то, что хотите владеть целиком. Конструктор — это аренда. Сегодня тарифы одни, завтра другие, послезавтра платформа меняет правила. Если ваш бизнес критически зависит от сайта — вам нужно владеть кодом и сервером.

Что спрашивать у разработчика перед стартом, чтобы не получить сюрпризы:

• Какая цена и что в неё входит? Фикс или почасовка?
• Что я получу после запуска? Код, сервер, документация — или только доступ к админке?
• Что будет, если я захочу сменить разработчика через полгода? (Ответ «ничего страшного» — это хороший знак.)
• Как будет устроена модерация / роли / интеграция? (Если разработчик отвечает абстрактно — он ещё не думал над вашим кейсом.)

Этот маркетплейс мы запустили в срок и в бюджет. Сейчас клиент планирует вторую фазу. Мой главный вывод из этого проекта — фиксированная цена работает, если с самого начала честно определить границы первой версии. Всё, что не вошло в первую версию, идёт в фазу два. Без этого любой фикс превращается в бесконечную почасовку, просто замаскированную.