Интерактивный генплан: из чего складывается цена и срок разработки

Интерактивный генплан жилого комплекса застройщики заказывают на этапе активных продаж: покупатель выбирает корпус, поднимается по этажам и кликает на квартиру прямо на карте, а отдел продаж видит актуальный статус без ежедневной сверки таблиц в Excel. За последние два года ко мне несколько раз приходили с одним и тем же вопросом: почему у одной студии похожая карта стоит 120 000 ₽, а у другой 450 000 ₽ за задачу, которая на брифе выглядит одинаково. Разница в архитектуре решения и в объёме интеграций, и в этой статье я раскладываю её по составляющим.

Из чего собран интерактивный генплан жилого комплекса

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

• Схема территории с корпусами, привязанная к реальной геометрии участка (часто её присылают в виде DWG или PDF от архитектурного бюро, и нужно перевести это в векторный формат для веба).
• Разрез корпуса по этажам с переходом от общего плана к конкретной секции.
• Поэтажный план с квартирами, где каждая квартира кликабельна и подсвечена цветом по статусу: свободна, забронирована, продана.
• Карточка квартиры с планировкой, метражом, ценой и кнопкой заявки или скачивания PDF.
• Фильтры по цене, площади, количеству комнат и виду из окна.
• Админка, через которую менеджер меняет статус квартиры без разработчика.

Каждый из этих пунктов можно сделать быстро и грубо, а можно доработать под конкретный ЖК с анимацией переходов, адаптивом под мобильные и синхронизацией с учётной системой. Отсюда и разброс цен на рынке от 60 000 до 500 000 ₽ и выше за похожую на первый взгляд задачу, в зависимости от студии и глубины проработки.

Три уровня сложности и разброс цен

Я обычно делю такие проекты на три уровня и в брифе сразу спрашиваю заказчика, какой из них реально нужен на старте продаж, а какой можно добавить позже.

Базовый уровень закрывает задачу для одного корпуса на этапе, когда квартир мало и статусы меняются раз в день-два. Средний уже подходит для комплекса из 3-5 корпусов с активным потоком заявок. Продвинутый обычно берут девелоперы с несколькими проектами в портфеле, где карту потом переиспользуют для каждого нового ЖК.

На чём технически делают карту жилого комплекса: SVG, Canvas или готовый конструктор

Для небольшого комплекса, где счёт квартир идёт на сотни, я почти всегда беру SVG. Векторная разметка легко масштабируется без потери качества, каждая квартира это отдельный элемент с собственными обработчиками кликов, и такую карту проще подключить к любой системе стилей на сайте. Дизайнер отрисовывает корпуса в Figma или Illustrator, я перевожу разметку в чистый SVG и навешиваю логику поверх.

Когда речь о комплексе на 20 и больше корпусов с несколькими тысячами квартир, чистый SVG начинает тормозить в браузере, особенно на слабых мобильных устройствах. Тут я перехожу на Canvas или WebGL: карта рендерится как графика, а не как DOM-дерево из тысяч элементов, и интерфейс остаётся отзывчивым даже при зуме и панорамировании.

Отдельный вопрос: можно ли обойтись готовым конструктором вместо разработки с нуля. Готовые виджеты для генпланов существуют, но они почти всегда рассчитаны на типовую верстку и плохо стыкуются с фирменным дизайном застройщика, а доработать чужой виджет под нестандартную планировку корпуса иногда выходит дороже, чем сделать карту своими руками. Если у заказчика уже есть сайт на Tilda, я обычно встраиваю карту как кастомный скрипт поверх существующей страницы, это быстрее и не требует переноса сайта на другую платформу.

Шахматка квартир и синхронизация статусов

Шахматка, то есть таблица со статусами всех квартир, обычно уже ведётся у застройщика в 1С, amoCRM или в общей Google Таблице, и карта должна показывать те же данные, что видит отдел продаж, без задержки в пару часов. От того, как организована синхронизация, зависит половина сметы на продвинутый уровень.

Я вижу три рабочих варианта.

• Ручное обновление через админку. Менеджер сам кликает на квартиру и меняет статус. Подходит для небольшого потока сделок, ничего лишнего не требует, но при пяти-шести менеджерах статусы быстро расходятся с реальностью.
• Синхронизация по расписанию. Скрипт раз в 10-30 минут забирает данные из Excel, Google Таблицы или выгрузки из 1С и обновляет статусы на карте. Такую связку я обычно собираю на n8n, это дешевле, чем писать кастомный импортер с нуля, и заказчик сам может поменять источник данных без моего участия.
• Реалтайм через API. Карта подключается напрямую к базе CRM или к учётной системе, и статус меняется на сайте в момент, когда менеджер закрывает сделку в 1С. Это самый дорогой вариант, но именно он снимает риск, что клиент забронирует уже проданную квартиру.

Для интеграций с 1С и промышленными CRM я обычно закладываю отдельный backend на Laravel, потому что там нужна нормальная бизнес-логика вокруг статусов, а не просто прокладка между таблицей и фронтендом.

Интеграция генплана с CRM и учётными системами

Карта без интеграции с CRM решает только визуальную задачу: клиент посмотрел, но заявка всё равно уходит по почте или в мессенджер, а менеджер вручную заносит её в систему. На среднем и продвинутом уровне я обычно подключаю прямую передачу заявки в Bitrix24 или amoCRM с указанием конкретной квартиры, корпуса и этажа, чтобы менеджер не тратил время на уточнение деталей у клиента.

Отдельно продумываю уведомления: когда клиент кликает «оставить заявку» на конкретной квартире, дежурный менеджер может получать сообщение в Telegram-бота сразу, без захода в CRM. Такой бот с базовой логикой обходится недорого и окупается за счёт скорости реакции на горячую заявку, особенно в комплексах с высоким спросом на вымывающиеся позиции.

Если у застройщика несколько проектов и в перспективе понадобится общая платформа для управления генпланами разных ЖК с единой админкой, разумнее сразу закладывать архитектуру полноценного сервиса, а не наращивать разовые доработки поверх лендинга. Такой сценарий я обычно обсуждаю отдельно как разработку веб-сервиса под конкретные бизнес-процессы, потому что там другой подход к проектированию базы данных и API с самого начала.

Сроки разработки: из каких этапов складывается срок

Срок почти всегда упирается не в код, а в подготовку исходных данных. Вот из чего он реально складывается на моих проектах.

• Аналитика и прототип: 3-5 дней. Смотрю, что есть у застройщика (DWG-файлы, PDF-планы, таблицы со статусами), фиксирую структуру данных.
• Векторизация и подготовка графики: 1-2 недели. Самый недооценённый этап: если чертежи от архитекторов не в цифровом виде или в них нестыковки между этажами, время уходит именно сюда.
• Разработка карты и фронтенда: 2-3 недели для базового и среднего уровня, 4-6 недель для продвинутого с несколькими ЖК.
• Интеграции с CRM и учётной системой: 1-3 недели в зависимости от того, есть ли у системы нормальное API или придётся городить экспорт через файлы.
• Тестирование на реальных данных и правки: 3-5 дней, обязательно с проверкой на мобильных устройствах, потому что большая часть трафика с карточек объектов идёт со смартфонов.

Если данные от застройщика приходят в порядке и API учётной системы открыт, продвинутый уровень укладывается в 8-10 недель. Когда чертежи нужно перерисовывать вручную, а интеграция с 1С делается через выгрузки раз в сутки, срок вырастает до 12-14 недель, и я всегда предупреждаю об этом на этапе оценки, а не по факту сорванного дедлайна.

Частые вопросы

Можно ли сделать интерактивный генплан на Tilda?

Да, для базового и части среднего уровня это рабочий вариант: карта встраивается кастомным скриптом поверх страницы ЖК, а данные о статусах подтягиваются через внешний сервис. Для реалтайм-синхронизации с 1С на большом комплексе Tilda как платформа становится узким местом, и я обычно предлагаю вынести логику в отдельный сервис, оставив на Tilda только витрину.

Сколько стоит поддержка генплана после запуска?

Отдельно от разработки. У меня техподдержка сайтов и сервисов стоит от 15 000 ₽ в месяц и покрывает обновление данных, правки в логике фильтров и реакцию на сбои синхронизации с CRM. Бесплатное сопровождение в стоимость разработки не включаю, потому что нагрузка на поддержку сильно разнится от проекта к проекту.

Как часто нужно обновлять статусы квартир на карте?

Зависит от темпа продаж. При нескольких сделках в неделю хватает синхронизации раз в 20-30 минут через n8n. При высоком спросе и риске продажи одной квартиры нескольким клиентам одновременно нужна связка с реальным временем через прямое подключение к CRM.

Что если у жилого комплекса несколько очередей строительства?

Тогда карту стоит проектировать сразу с учётом переключения между очередями и датами сдачи, это отдельный уровень навигации поверх корпусов. Такую многоочередность закладываю в архитектуру ещё на этапе прототипа, потому что переделывать структуру данных после запуска первой очереди дороже, чем учесть это заранее.