Launch Plan v2 — offplan.online

Версия: 2.0 Дата: 2026-04-22 Источники: VolumeVision_LaunchPlan v1.docx + звонок с командой (апрель 2026) Статус: draft — финальные эстимейты уточнить с командой Ильи

Контекст продукта

Продукт существует и работает — 3.5 года разработки, ~90k LOC (frontend-heavy). Три компонента:

• Sales App — публичная страница проекта: 360° walkthrough (exterior/interior), views (level/unit с балкона), floorplates, gallery, unit list. Feature flags — каждый проект показывает только нужные модули.
• Admin Panel — управление контентом: юниты, floor plans, здания, amenities, галерея, брендинг, feature toggles. Существует и работает. Задача — улучшение UX и визуала, не перестройка с нуля.
• API — собственный API на котором построены оба приложения. Основа для CRM-интеграций.

Продукт приносит доход (кейс: +$400k дохода студии благодаря walkthroughs). Цель — productise его в self-serve SaaS для рендер-студий.

⚠️ О таймингах: Текущий цикл — 2 недели спринт + 1.5–2 недели QA до деплоя. Фазы ниже учитывают это. Финальные эстимейты уточнить с командой Ильи.

Блок 1 — Вопросы перед запуском

1.1 — 30 операционных вопросов

1.2 — Вопросы из обсуждения команды

Блок 2 — Фазы запуска

Фаза 1 — Обязательный минимум перед запуском (~6–8 недель)

01 — Self-serve онбординг [Критично]

Что это: Полный путь от регистрации до первого опубликованного проекта без участия команды VV.

Почему критично: Если студия застревает на любом шаге — она уходит и не возвращается. B2B SaaS живёт первыми 10 минутами пользователя. Сейчас настройка домена требует участия команды VV — это не масштабируется на 20+ агентств.

Что нужно сделать:

• Экран приветствия после регистрации с onboarding wizard (3–4 шага максимум)
• Автоматическая настройка поддомена: studio-name.offplan.online без ручной работы со стороны VV
• Возможность подключить кастомный домен: инструкция с DNS-записями прямо в панели
• Шаблонный первый проект или demo-данные чтобы студия сразу видела как это выглядит
• Email-последовательность: день 1, день 3, день 7 — помощь с настройкой

Метрика успеха: студия от регистрации до первого проекта за <30 минут без обращений в поддержку.

02 — Страница продаж + подписка [Критично]

Что это: Лендинг с описанием ценности + биллинговая система.

Почему критично: Без страницы продаж невозможно масштабировать — каждый клиент требует ручных переговоров. Без биллинга нет выручки. Даже в beta важно протестировать воронку оплаты.

Что включить на странице продаж:

• Главный месседж: «Всё в одном месте — рендеры, walkthroughs, floor plans, статусы продаж»
• Конкретный кейс с цифрами: +$400k дохода благодаря walkthroughs — это золотой аргумент
• Сравнение с конкурентами (Matterport, Kuula) — почему VV лучше для продаж недвижимости
• Тарифные планы с чёткими лимитами (проекты, рендеры, пользователи)
• CTA: Start free trial — без карты, 3 месяца бесплатно

Биллинг — технически:

• Stripe или Paddle — оба поддерживают EU VAT, invoice для B2B, мультивалюту
• Paddle предпочтительнее если нет EU-юрлица: они выступают Merchant of Record и берут EU VAT на себя
• Webhook от биллинга → автоматическая активация/деактивация аккаунта
• Self-service: студия сама меняет план, скачивает invoice, отменяет

03 — Legal: ToS, Privacy Policy, GDPR [Юридика]

Что это: Юридические документы защищающие VV и необходимые для легальной работы в Европе.

Terms of Service — ключевые разделы:

• Стороны: VV — платформа, студия — subscriber, девелопер/покупатель — end user
• Ограничение ответственности: VV не отвечает за контент студий. Liability cap = 12 месяцев оплаты
• Интеллектуальная собственность: VV владеет платформой, студия — своим контентом
• Прекращение аккаунта: grace period → suspend → удаление данных через 90 дней
• SLA: гарантированный uptime 99.5%

Privacy Policy — ключевые разделы:

• Двухуровневая структура: VV — контроллер данных студий; студии — контроллеры данных своих клиентов
• Lawful basis для каждой категории: договор (биллинг), легитимный интерес (аналитика), согласие (маркетинг)
• Retention policy: активный аккаунт, 90 дней после отмены, логи 12 месяцев
• Права субъектов: access, erasure, portability, right to object

Data Processing Agreement (DPA):

• DPA обязателен по GDPR Art. 28 — без него студия технически нарушает GDPR
• Должен покрывать: что обрабатывается, как, где хранится, субпроцессоры (Stripe, Hotjar и т.д.)

Cookie consent: обязателен на публичных страницах до загрузки Hotjar/Clarity.

Юрлицо: если VV FZ-LLC (UAE) работает с EU-пользователями — нужен EU Representative по GDPR Art. 27. Альтернатива: EU-юрлицо (UK Ltd, Malta, Estonia e-Residency).

Совет: Termly или iubenda для базовых документов, но DPA — только через EU GDPR-юриста.

04 — Улучшение admin-панели [UX]

Что это: Панель существует и работает. Задача — сделать её понятнее, красивее и удобнее для студий.

Что уже работает (на основе звонка):

• Dashboard с счётчиками: Units, Floor Plans, Views, Amenities, Buildings
• Features Management с toggle-переключателями (Walkthroughs, Price List, Unit Statuses)
• Units с room information, panorama upload, hotspots
• Управление этажами, level views, gallery, брендинг, Welcome Media

Что улучшаем:

• Управление несколькими проектами и переключение между ними
• Приглашение клиента-девелопера с ограниченным доступом
• История изменений — кто и что менял
• Статистика: просмотры, время на странице, популярные юниты
• Уведомления: клиент просмотрел, лид оставил заявку
• Биллинг блок: текущий план, следующий платёж, invoice
• Визуальный редизайн: более современный и понятный интерфейс
• Мобильная версия admin — менеджер студии часто работает не за компьютером

Принцип: Студия управляет всем самостоятельно — VV не должна быть bottleneck. Действия «один клик» для частых операций.

05 — Inline-редактирование для клиентов [UX]

Что это: Возможность для девелопера менять данные прямо на публичной странице проекта, не заходя в admin.

Проблема которую решает: Сейчас: студия → admin → обновляет данные → отправляет ссылку клиенту. Медленно. С inline: девелопер сам обновляет цену или статус прямо на сайте. В реальном времени.

Что редактируется inline:

• Цена юнита (самое частое изменение)
• Статус: available / reserved / sold
• Floor plan замена
• Описание и спецификации

Технически:

• Отдельная роль «клиент» с ограниченными правами — только свой проект
• Edit mode toggle: кнопка включает режим редактирования на фронте
• Изменения через API с подтверждением
• Audit log: история всех изменений с timestamp

Приоритет: фича Фазы 1, но если не успевает — переносится в Фазу 2. Базовый admin покрывает эту потребность, inline — улучшение UX.

Фаза 2 — Операционная готовность (~4–6 недель после Фазы 1)

06 — AI-поддержка с первого дня [Tech]

Что это: Система поддержки на базе AI, 24/7. Живой оператор — только для сложных кейсов.

Архитектура:

• Tier 1 — AI-бот: отвечает на 80% вопросов мгновенно. Обучается на базе знаний VV.
• Tier 2 — Живой оператор: подключается если бот не знает ответа или клиент просит человека
• Инструменты: Intercom, Crisp, или Help Scout с AI-надстройкой

Как выстроить базу знаний с нуля:

• Записать каждый шаг onboarding как отдельную статью
• Каждое обращение в поддержку = новая статья если вопрос не был в базе
• Видео-гайды: Loom или короткие MP4 — снижают вопросы на 40–60%

Ключевой принцип: всё что делаете сейчас (статьи, видео, ответы в чате) — сразу идёт в базу знаний бота. Не создавать дважды.

07 — База знаний: статьи + видео-гайды [Контент]

Приоритетные статьи (порядок важен):

1. Быстрый старт: от регистрации до первого проекта за 15 минут
2. Кастомный домен: как настроить DNS, что делать если не работает
3. Добавление проекта: структура, Buildings → Levels → Units → Rooms
4. Загрузка panorama и настройка hotspots
5. Управление floor plans и связь с юнитами
6. Invite клиента: права доступа, что он видит и может делать
7. Биллинг: как сменить план, скачать invoice, отменить подписку
8. Features: что включает/выключает каждый toggle

Формат: статьи 300–500 слов + скриншоты, Loom-видео максимум 3–5 минут, checklist в конце каждой статьи.

08 — Heatmap и аналитика использования [Аналитика]

Что устанавливаем:

• Hotjar или Microsoft Clarity (бесплатный) — heatmaps, session recordings, funnel analysis
• PostHog или Mixpanel — product analytics: события, retention, feature adoption
• Google Analytics 4 — трафик на публичных страницах проектов

Ключевые метрики для beta (3 месяца):

• Time to first project: сколько времени от регистрации до создания первого проекта
• Feature adoption rate: какой % студий включает Walkthroughs, Price List, Unit Statuses
• Session recordings admin: где студии останавливаются, кликают в пустоту, уходят
• Heatmap публичной страницы: что смотрят покупатели квартир, на что кликают
• Support ticket причины: топ-5 вопросов = топ-5 UX проблем

GDPR и аналитика: Hotjar/Clarity требуют cookie consent до загрузки. Microsoft Clarity — GDPR-compliant из коробки. Анонимизация IP обязательна при сборе данных EU-пользователей.

09 — Нагрузочное тестирование [Tech]

Сценарий тестирования:

• 20 агентств × 5 проектов = 100 проектов одновременно
• Каждый проект: 10–15 юнитов, 3–5 panorama на юнит, floor plans, медиа
• Нагрузка: 50–100 одновременных посетителей на публичные страницы
• Стресс-тест: 200+ человек одновременно (сценарий выставки)

Что тестировать:

• Время загрузки 360° panorama на разных скоростях соединения
• Walkthrough без артефактов при 50+ одновременных сессиях
• Admin-панель: одновременное редактирование несколькими пользователями
• Биллинг: webhooks при upgrade/downgrade/cancel не теряются

Инструменты: k6 или Apache JMeter (нагрузка на API), Lighthouse (Performance score цель 80+), WebPageTest (реальные условия, разные географии).

Оптимизации которые скорее всего понадобятся: CDN для медиа (Cloudflare), lazy loading для panoramas, image compression pipeline при загрузке.

Фаза 3 — Рост и интеграции (~1–3 месяца после запуска)

10 — API / Webhooks / MCP для CRM [Tech]

Почему это первый вопрос от агентств: у девелоперов уже есть CRM с базой покупателей. Они хотят чтобы лид с Register Interest автоматически попадал в их систему.

Что реализовать в первую очередь (Webhooks):

• Register Interest: новый лид → webhook → CRM девелопера
• Unit status change: Available → Reserved → Sold → уведомление в CRM
• Price change: обновление цены → синхронизация с CRM
• New project created: уведомление в Slack/email менеджеру

MCP Server:

• Позволяет AI-агентам управлять VV через натуральный язык
• Пример: «Покажи все доступные 3-bedroom юниты в проекте X» — AI запрашивает через MCP
• У VV уже есть API — нужно только добавить MCP wrapper
• Хорошая PR-история: «Первая PropTech платформа с MCP»

Документация API: Swagger/OpenAPI документация, sandbox environment для разработчиков, готовые примеры подключения для HubSpot, Salesforce, Pipedrive.

11 — Дистрибуция: 20 агентств в beta [Рост]

Почему эта стратегия сильна: VV уже имеет доверие в сообществе рендеринговых студий. Студии — мультипликаторы: каждая приводит 3–10 девелоперов-клиентов.

Как структурировать beta-программу:

• Отбор 20 студий: разные страны, размеры, специализации
• Условия: 3 месяца бесплатно в обмен на еженедельный feedback + разрешение на кейс-стади
• Dedicated Slack канал или WhatsApp группа для beta-студий
• Monthly call: 45 минут демо нового функционала + сбор feedback

Что получаете взамен: 100 реальных проектов для нагрузочного тестирования, реальные use cases, testimonials для страницы продаж, первые платящие клиенты после beta.

Beta — это не просто бесплатный доступ. Это структурированная программа с чёткими обязательствами с обеих сторон.

12 — Биллинг и тарифные планы [Монетизация]

Варианты модели монетизации:

• По количеству активных проектов: Starter (3), Pro (10), Agency (unlimited)
• По количеству рендеров/panoramas: base quota + overage
• По студиям / пользователям: per-seat модель
• Hybrid: базовая подписка + pay-per-project

Рекомендуемая структура тарифов (предварительно):

Технически: Stripe Billing или Paddle, metered billing для рендеров, annual discount 20%, grace period 14 дней при неоплате.

Совет: не запускайте с более чем 3 тарифами. Простота конвертирует лучше.

13 — Compare units + remote access для агентов [Roadmap]

Compare units: покупатель всегда сравнивает несколько юнитов. Compare view: выбрать 2–3 юнита → таблица сравнения площадь/цена/этаж/вид/статус. Это фича для конечного покупателя, увеличивает conversion девелопера.

Remote access для агентов: агент ведёт покупателя удалённо по 3D-туру. Технически: WebRTC или cursor sharing через WebSocket. Сильный differentiator — конкуренты этого не делают.

Почему это Фаза 3: продукт уже работает хорошо без этих фич. Beta-студии дадут чёткий сигнал насколько они критичны. Heatmap покажет если покупатели пытаются сравнивать юниты — это будет сигналом к приоритизации.

Блок 3 — Команда и пропускная способность

⚠️ Требует уточнения с командой Ильи — эстимейты ниже предварительные.

Текущая команда

Пропускная способность

Текущий цикл: 2 недели спринт → 1.5–2 недели QA → деплой. Два типа деплоев: мелкие правки (~40–50) и большие логические изменения — всегда отдельно.

По Денису: он является наиболее активным контрибьютором на frontend/content. Является ли он реальным узким горлышком — необходимо получить от команды Ильи примерный эстимейт по каждой задаче Фазы 1 в разбивке по ролям. После этого будет ясно можно ли распределить нагрузку или нужно усиление.

Блок 4 — Метрики успеха

Открытые вопросы

• [ ] Финальные эстимейты по каждой задаче Фазы 1 — уточнить с командой Ильи
• [ ] Эстимейт по Денису (frontend) — подтвердить или опровергнуть узкое горлышко
• [ ] Stripe vs Paddle для биллинга?
• [ ] EU-юрлицо или EU Representative для GDPR?
• [ ] Какие CRM приоритетны для первой webhook-интеграции?
• [ ] Целевой MRR после beta?
• [ ] Статус текущей AI-инфраструктуры — что уже построено за последние 3 месяца?
• [ ] Inline-редактирование: Фаза 1 или Фаза 2?

Связанные файлы

• plans/VolumeVision_LaunchPlan v1.docx — исходный план (архив, первая версия)
• workstreams/ — исполнительные единицы (создаются после ратификации плана)