Версия: 3.1 (ревизия 2026-04-27, CONV-10) Дата: 2026-04-24 → ревизия 2026-04-27 Источники: launch-plan-v2 + звонок с Ильёй (2026-04-24) + UX-аудит VV Admin (2026-04-23) + заметки Сергея из ручного тестирования + Notion Learnings DB + звонок с Ромой (2026-04-24) + видео-звонок с Надеждой (Dubai sales manager, 2026-04-23) Статус: draft — на обсуждение с product team и tech team Предыдущая версия: plans/launch-plan-v2.md (архив) Визуальный appendix: docs/launch-plan-v3-visual.html (концепция админки + v4 mockup) Changelog: см. Appendix G в конце документа

Executive Summary

Это план вывода offplan.online в лайв как публичный self-serve SaaS. Документ рассчитан на обсуждение менеджментом (product team + tech team), чтобы увидеть что критично, с чего начать и убедиться что ничего не упущено. Задачи разложены по 4 стадиям, 21 фазе и ~90 подзадачам. Тайминги умышленно отсутствуют — вместо них стоит маркер ⏱ Требует эстимейт от tech team там, где нужны сроки.

Четыре стадии

Стадии и критичность — матрица

Что это значит: вся критичная работа сосредоточена в Стадии 1 (подготовка). Стадия 2 ведёт работу параллельно с пилотом. Стадии 3 и 4 — итеративно по фидбеку.

Изменения в ревизии 3.1 (2026-04-27):

• Стадия 1: 5 фаз → 8 фаз (добавлены 1.3 MCP Wrapper и 1.8 Sales-app UX redesign; перенумерованы все остальные)
• Стадия 4: 5 фаз → 4 фазы (4.1.5 MCP Wrapper перенесён в Стадию 1)
• Приоритеты внутри Стадии 1 переупорядочены: Visual Redesign теперь 1.1 (был 1.6), Security теперь 1.7 (был 1.1)

1. Цель плана

Вывести offplan.online в лайв как публичный self-serve SaaS для продажи off-plan недвижимости. Продукт white-label: рендер-студии и агентства регистрируются, подключают свой поддомен, сами создают проекты для своих клиентов-девелоперов, платят подписку.

Что в скоупе плана:

• Всё что нужно сделать с технической, продуктовой, юридической и операционной стороны, чтобы запустить публично
• Пилотный запуск с 20 студиями как стадия валидации (не финальная цель)
• Инфраструктура поддержки клиентов и сбора фидбека
• Масштабирование, монетизация, интеграции (post-launch)

Что вне скоупа:

• Создание нового контента / 3D / CGI (остаётся у студий)
• Ручная поддержка клиентов (всё self-serve + AI + минимум human)
• Внутренние процессы VV (продолжают работать как есть для существующих клиентов)

2. Методология

Маркеры

Каждая подзадача имеет набор маркеров для сканируемости:

Правила чтения

• Фазы внутри стадии не обязательно последовательные — многие могут идти параллельно (security + legal + sales page)
• Порядок = приоритет, а не временная последовательность (тайминги отсутствуют до эстимейтов Ильи)
• Каждая подзадача — кандидат на отдельный workstream для /build

Стадия 1 — Подготовка к пилотному запуску

Цель стадии: продукт технически, юридически и по UX готов к тому, чтобы пригласить первых студий на закрытое тестирование. Нет публичной регистрации, нет маркетинга, но инфраструктура, security, биллинг, онбординг и legal — работают.

Условие выхода из стадии: команда может безопасно пригласить 3-5 первых студий, и те могут пройти путь signup → домен → первый проект → оплата без помощи VV.

🎯 Порядок приоритетов внутри Стадии 1 (ревизия 2026-04-27)

После звонков с Ромой и Надеждой фазы переупорядочены. Логический порядок (для чтения и приоритизации работ):

Физический порядок в этом документе оставлен прежним для совместимости с предыдущими ссылками (1.7 Security сначала по тексту, но 1.1 Visual Redesign — Priority #1 для исполнения). Используйте таблицу выше для приоритизации.

Фаза 1.7 — Security & Infrastructure Foundation

Понижен в приоритете (ревизия 2026-04-27): Сергей и Рома договорились что 1.7 — это базовый уровень, который выполняет tech team как чек-лист. Не первоочередная задача со стороны product team. Илья гарантирует, что всё необходимое сделано до запуска пилота. Phase остаётся в Стадии 1 (нельзя пропустить), но не блокирует приоритеты #1-3.

Без этой фазы нельзя давать продукт клиентам — риск data breach между студиями, DoS от одного bad actor, потери данных при крушении базы, невозможность расследовать инцидент.

1.7.1 — Tenant isolation audit & hardening

Приоритет: Критично · Отдел: Tech · ⏱ · ❓

Что это: Audit существующей изоляции между студиями и fix любых найденных gaps. Студия A не должна видеть данные, медиа или метаданные студии B ни через UI, ни через API, ни через direct media URL, ни через search/autocomplete endpoints.

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

• Документировать как сейчас работает изоляция (database-level / application-level / оба?)
• Аудит каждого API endpoint на cross-tenant leak (включая GET/LIST с фильтрами)
• Аудит storage: могут ли медиа-URL одной студии быть угаданы / перебраны
• Автоматические регрессионные тесты изоляции (добавить в CI)
• Penetration test (внутренний или внешний — см. открытый вопрос)
• Fix любых gaps + документация security posture для DPA

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

• ❓ Внешний audit (ROI: объективность + опыт) или внутренний (дешевле, но bias)?
• ❓ Бюджет на pen-test если внешний?

Зависит от: — (базовая задача) Блокирует: Фазу 1.6.3 (DPA ссылается на security measures)

1.7.2 — Rate limiting infrastructure

Приоритет: Критично · Отдел: Tech · ⏱

Что это: Защита от злоупотреблений: кто-то регистрируется и пытается положить сервис массовой загрузкой больших файлов, DDoS на API, brute-force на auth. Сейчас лимитов скорее всего нет или они базовые.

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

• API rate limits per IP (anonymous / authenticated / per tenant)
• Upload rate limits: max размер файла, max файлов в минуту/час, max concurrent uploads
• Login attempts: exponential backoff + temporary lockout
• Password reset: лимит per email в день
• Abuse detection: unusual patterns (напр., 1000 unit-creations за минуту)
• Dashboard для админов VV чтобы видеть текущее использование по tenant
• Настройки лимитов в конфиге (не хардкод) — чтобы тюнить без релиза

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

• Какие числа сейчас хардкоджены / где?
• Использовать готовое (Cloudflare, Redis rate limiter, nginx) или кастомно?

Зависит от: — Блокирует: Стадию 2 (без этого опасно приглашать даже 5 студий)

1.7.3 — Error tracking + alerting

Приоритет: Критично · Отдел: Tech + Ops · ⏱

Что это: Мы должны узнавать о проблемах раньше клиентов. Сейчас если API 500-ит, мы узнаём когда клиент пишет. Это неприемлемо для SaaS.

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

• Sentry (или аналог — Bugsnag, Rollbar) на frontend и backend
• Source maps для frontend чтобы ошибки читались
• Tagging по tenant / environment / release
• Alert routing: Slack/Telegram/email для разных severity
• On-call rotation — кто получает пейджинг ночью
• Dashboard: топ ошибок за день / неделю
• Integration с релизами — знать в каком build появилась ошибка

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

• Какой alerting канал основной (Telegram / Slack / email)?
• Есть ли 24/7 on-call или только working hours?

Зависит от: — Блокирует: —

1.7.4 — Backup & disaster recovery

Приоритет: Критично · Отдел: Tech + Ops · ⏱

Что это: Если БД упала или студия случайно удалила проект — должны уметь восстановить. Сейчас backup может быть есть, но никто не знает процедуру restore.

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

• Daily database backups (hourly для критичной БД?)
• Media backups (S3/bucket versioning + regular snapshot)
• Retention policy: daily 7 дней, weekly 4 недели, monthly 12 месяцев
• Restore drill — провести учения: полное восстановление с нуля из backup, замерить время
• Документированная процедура restore (runbook)
• RTO (Recovery Time Objective) и RPO (Recovery Point Objective) — формальные цели
• «Undelete» для студий — отдельная фича, grace period 30 дней на восстановление удалённого проекта

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

• Где хранить off-site backup (другой регион / другой провайдер)?
• Какой RTO приемлем для пилота? Для публичного?

Зависит от: — Блокирует: Фазу 1.6.1 (ToS упоминает SLA)

1.7.5 — DDoS / abuse protection

Приоритет: Критично · Отдел: Tech · ⏱ · ❓

Что это: На публичной стороне (страницы проектов) и на admin — защита от volumetric attacks, bot scraping, credential stuffing.

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

• WAF (Cloudflare / AWS WAF / альтернатива)
• CDN-based DDoS protection для публичных страниц
• Bot detection на signup / login (reCAPTCHA / hCaptcha / Turnstile)
• IP reputation blocking (tor exit nodes, known abuse)
• Анти-scraping на публичных API (headers, patterns)
• Мониторинг необычных трафик-паттернов

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

• ❓ Cloudflare Pro/Business/Enterprise — какой план покрывает наши нужды?
• ❓ Стоимость приемлема для 20 студий? Для 200?

Зависит от: — Блокирует: Стадия 3 (публичный запуск без WAF — самоубийство)

Было: 1.1.6 Secrets management + key rotation (старая нумерация) Перенесено в Стадию 3 — Фаза 3.5.4. Для пилота .env + CI env vars достаточно; Vault / AWS Secrets Manager имеет смысл до публичного запуска, а не до пилота.

Фаза 1.2 — Self-Serve Onboarding

Путь от регистрации до первого опубликованного проекта без единого обращения в VV. Это то, что превращает продукт из «нужно звонить» в SaaS.

1.2.1 — Signup & account creation (5-level tenant access architecture)

Приоритет: Критично · Отдел: Tech + UX · ⏱ · ❓

Расширено (ревизия 2026-04-27, фидбек Ромы): Сигнап теперь не «email + пароль» — это архитектура 5-уровневого доступа с tenants и nested permissions. См. подробно в фазе 1.2.7.

Что это: Базовый signup flow: форма → подтверждение email → аккаунт активен. Плюс опции SSO для ускорения. Архитектурно — это вход в multi-tenant систему с 5 уровнями доступа (см. 1.2.7 для permission model).

5 уровней доступа (новое от Ромы):

1. VV master — Сергей, Рома, Илья — могут зайти в любой tenant для помощи
2. Studio admin — владелец аккаунта студии (всё внутри своего tenant)
3. Studio employees — сотрудники студии с назначаемыми правами
4. Developer client — клиент студии (девелопер), приглашён студией
5. Developer client employees / agents — приглашены девелопером

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

• Форма регистрации Studio admin: email, пароль, название студии, страна
• Архитектура tenant'ов: studio = root tenant, dev clients = child tenants
• Требования к паролю (по NIST: 8+ символов, не в breach-базах)
• Verification email с токеном (expires 24h)
• Re-send email если пользователь не получил
• Social SSO: Google (минимум) — ускоряет signup в 3-5 раз
• Опционально: Microsoft SSO / Magic Link / Email-only login
• Rate limit на signup per IP (предотвращает bot-fermy)
• Invite-flow для уровней 3-5 (employees, dev clients, dev agents — не самостоятельный signup, только по invite от уровня выше)
• VV master access реализован отдельно (impersonation / support мode)

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

• ❓ Какие SSO провайдеры обязательны на старте (Google / Microsoft / Magic Link)?
• ❓ MFA опциональный или обязательный с запуска?
• ❓ Архитектурно — готова ли существующая база к 5 уровням или нужен рефактор?
• Email provider для transactional (SendGrid / Postmark / Resend)?

Зависит от: Фаза 1.7.2 (rate limiting) Блокирует: Фазу 1.2.4 (wizard), 1.2.7 (team management — сама модель строится здесь)

1.2.2 — Per-project subdomain provisioning (rewrite — фидбек Сергея 2026-04-24)

Приоритет: Критично · Отдел: Tech + Ops · ⏱

Переписано (ревизия 2026-04-27): Раньше было «студия получает studio-name.offplan.online». Сергей подтвердил — студиям отдельный домен не нужен, нужен проектам: project-name.offplan.online (default) или project-name.client.com (paid tier, см. 1.2.3). Студия получает только админ-портал.

Что это: Каждый созданный проект автоматически получает поддомен project-slug.offplan.online, на котором публикуется sales-app. Студия указывает slug в момент создания проекта. Без ручной работы VV.

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

• Wildcard DNS *.offplan.online → origin server
• Automatic SSL (Let's Encrypt wildcard или per-subdomain)
• Имя поддомена per project валидируется: reserved words (admin, www, api, mail, app...), длина, символы, уникальность
• Сервер резолвит subdomain → project_id на уровне middleware
• Smooth experience: project created → сразу видит marina-residences.offplan.online работает
• Studio admin портал — на одном фиксированном поддомене (например, app.offplan.online), не per-studio
• Опционально: studio default subdomain studio-name.offplan.online как hub-page со списком проектов студии (low priority)

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

• Можно ли сменить slug проекта позже (yes/no/один раз)?
• Что если slug уже занят другой студией — глобальная уникальность или per-tenant?

Зависит от: Фаза 1.2.1 (signup) Блокирует: Фазу 1.2.3 (custom domain для проектов)

1.2.3 — Custom domain self-serve (для проектов, не студий)

Приоритет: Критично · Отдел: Tech · ⏱

Переписано (ревизия 2026-04-27): Раньше — «студия хочет свой projects.studio.com». Корректировка от Сергея: custom domain для проектов, не для студий. Например, девелопер хочет palmresidences.com для своего sales-app, а не palm-residences.studio.com.

Что это: Для конкретного проекта студия (или девелопер через студию) хочет свой домен — например palmresidences.com или marina.developer.ae. В админке инструкции что прописать в DNS, verification flow, SSL автоматом. Это premium feature (paid tier).

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

• Форма «добавить custom domain» — на уровне проекта (не tenant'a студии)
• Показать две записи которые надо добавить (CNAME + TXT для верификации)
• Автоматическая проверка DNS propagation (каждые 5 мин в первый час, потом реже)
• Статусы: pending / verified / SSL provisioning / active
• SSL provisioning (Let's Encrypt — автоматом после верификации)
• Error states: «DNS не пропагировался», «CNAME указывает не туда», «SSL выдача упала»
• Возможность откатиться на default поддомен если проблемы
• Tier-gating: custom domain доступен на Studio+ tier или paid add-on

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

• Сколько custom domains per project (1 — основной + redirects)?
• Что если домен уже использовался другим проектом (конфликт)?
• Можно ли transfer custom domain между проектами (например, при ребрендинге)?

Зависит от: Фаза 1.2.2 (per-project subdomain инфра) Блокирует: —

1.2.4 — Onboarding wizard (упрощён по итогам 2026-04-24)

Приоритет: Критично · Отдел: Design + Tech · ⏱

Изменения (ревизия 2026-04-27, фидбек Ромы):

• Шаг 2: убрать поле «тип проекта» (residential / commercial / mixed) — не нужно
• Шаг 4: убрать Slack-приглашение, оставить только email
• Убрать Skip-кнопку — wizard обязателен для новых аккаунтов (опытные опции — для следующих проектов)

Что это: После первого логина — 3-4 шага, которые за 10-15 минут доводят студию до первого опубликованного demo-проекта. Без wizard студия теряется в админке (см. UX-аудит CONV-7). Wizard обязательный, не пропускаемый.

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

• Шаг 1 — Studio profile: название, лого, бренд-цвет
• Шаг 2 — Первый проект: название + slug (для поддомена) — без поля «тип проекта»
• Шаг 3 — Контент: «залить свой» или «использовать demo-шаблон»
• Шаг 4 — Publish & share: превью, shareable link, email-приглашение коллег (Slack убран)
• Progress indicator, возможность прервать и вернуться (но не пропустить полностью)
• Skip-кнопка — убрана. Wizard обязателен для нового аккаунта
• Post-wizard dashboard с чекбоксом next steps («добавьте юниты», «настройте домен»)

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

• В какой момент триггерим первый email из Day 1 sequence (после signup / после wizard)?
• Что показывать если wizard прерван и пользователь возвращается через сутки?

Зависит от: Фазы 1.2.1, 1.4.3 (нужен рабочий path создания проекта) Блокирует: —

1.2.5 — Demo-проект vs Empty-state — попробовать оба через Claude Design

Приоритет: Высокий · Отдел: Product + Design · ⏱

Изменено (ревизия 2026-04-27, фидбек Ромы): Не выбирать заранее — сделать визуальные варианты обоих подходов через Claude Design + Figma, потом выбрать по результатам.

Что это: Либо студия получает готовый demo-проект (с fake buildings/units), который может клонировать или удалить, либо empty-state с intuitive tutorial overlay. Решение принимаем после визуальных проб.

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

• Сделать визуальные mockups обоих подходов через Claude Design (использовать существующую Figma)
• Сравнить UX по критериям: «новичок понимает что делать», time-to-first-value, не засоряет tenant
• Если demo: подготовить эталонный проект (3D, units, floor plans, gallery) на собственном контенте VV
• Если overlay: tooltips с pointer arrows, dismissable, персистентный state
• Лёгкое удаление demo-проекта (не засорять tenant)
• Опционально: «клонировать структуру demo в новый проект» (шаблон)
• Финальный выбор после визуальной оценки + 2-3 теста на реальных пользователях

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

• ❓ Demo-проект vs empty-state tutorial — finalize по итогам visual mockups
• Кто делает контент для demo-проекта (студия VV / внутренний)?

Зависит от: Фаза 1.2.4 (wizard предлагает выбор), Фаза 1.1 (брендбук — для визуального языка mockup'ов) Блокирует: —

1.2.6 — Email onboarding sequence (ОТЛОЖЕНО в Стадию 3)

Приоритет: Низкий → отложено · Отдел: Marketing + Tech

Отложено в Стадию 3 (ревизия 2026-04-27, фидбек Ромы): Сергей: «Не нужно об этом париться, пока мы не знаем флоу.» Email sequence строится после того как мы поймём реальный путь пользователя на пилоте. До этого — преждевременная оптимизация.

Что это (отложено): Автоматические письма на Day 1, 3, 7 для onboarding. Реализуется после Стадии 2 (пилот), когда виден реальный паттерн как студии используют продукт в первые дни.

Что вместо этого в Стадии 1:

• Один welcome email после signup (минимум — verification + ссылка на onboarding wizard)
• Один email-уведомление о приглашении team member (для 1.2.7)
• Простые transactional emails (billing, password reset) — без onboarding sequence

Открытые вопросы (для Стадии 3):

• Какой email provider + шаблонизатор (SendGrid / Postmark / Customer.io)?
• Кто пишет тексты (Marketing / Product team)?

Перенесено в: Стадия 3 — будет добавлено как новая фаза после анализа пилота

1.2.7 — Multi-level access (5 уровней) + team management

Приоритет: Критично · Отдел: Tech + Design · ⏱ · ❓

Значительно расширено (ревизия 2026-04-27, фидбек Ромы): Старая версия была «студия = несколько пользователей с ролями admin/editor/viewer». Это неполно. Реальная модель — 5 уровней доступа, каждый с своими permissions, видимостью и возможностью назначать роли вниз по иерархии. Перед началом работ — отдельная спецификация permission model.

Что это: Архитектура multi-tenancy с nested access — 5 уровней пользователей, у каждого свой scope видимости и permissions. Это критично для B2B (студия = несколько людей; девелопер = ещё несколько; их агенты — ещё). Без этого продукт не подходит ни одной серьёзной студии.

5 уровней доступа (от Ромы):

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

• Спецификация permission model (отдельный документ) — перед любым кодом
• Database schema: tenants (studio + dev client), users, roles, permissions, user_role_assignments
• UI «Invite team member» с выбором уровня и scope (per project / studio-wide / billing-only)
• Email-invitations с принятием
• Remove user (с transfer ownership option если это owner)
• Audit: кто из team изменил что (связано с 3.3.3 Audit log)
• Seat limit per план (совместимо с pricing 1.5.2 + 1.5.8)
• SSO на уровне студии — Google Workspace / Microsoft (enterprise tier)
• Invite expiration (7 дней), re-send invite
• VV master access — отдельный flow (impersonation, не «обычный» login)
• Granular permissions per project (см. фидбек Надежды — "доступ дать на конкретный проект, не на всю студию")

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

• ❓ Готова ли существующая архитектура к 5 уровням или нужен рефактор (вопрос Илье)?
• ❓ Permissions внутри Studio employees: предопределённые роли (Admin/Editor/Viewer) или granular?
• ❓ Studio-level SSO — в Стадии 1 или отложено в 4.2.5 (Enterprise)?
• ❓ Что с контентом removed user — остаётся или «unassigned»?
• ❓ Дев-клиент видит другие проекты другой студии (no — должна быть жёсткая изоляция)?

Зависит от: Фаза 1.2.1 (signup architecture) Блокирует: Стадию 2 (без team management многие студии не смогут пилотировать)

Фаза 1.3 — MCP Server Wrapper (NEW — перенесён из 4.1.5)

🔴 Critical, перенесён в Стадию 1 (ревизия 2026-04-27, по итогам разговора Сергея с Ромой): Раньше был 4.1.5 (Стадия 4, low-medium priority). Сергей: «Нам нужно самим, для себя и вообще для всех, построить MCP wrapper вокруг всей нашей административной части, вокруг всего нашего API. Это нужно сделать как можно быстрее. Если MCP есть, клиент может тупо через Claude создавать проект. Без этого не запускаться.»

Контекст и обоснование

Что такое MCP (Model Context Protocol): Открытый стандарт от Anthropic, позволяющий AI-моделям (Claude, GPT и др.) вызывать внешние API через стандартизированный интерфейс — как разработчик использует API, но через диалог.

Что значит MCP wrapper для offplan.online: Тонкий слой над существующим API, который превращает наши endpoints в "MCP tools" — действия, которые AI может вызывать. Студия открывает Claude и говорит:

«Создай новый проект — Dubai Marina Residences, 2 башни, в башне A 80 юнитов (1BR/2BR), в башне B 60 юнитов (3BR), launch June 2026.»

Claude вызывает наши MCP tools, проект создан за 30 секунд. Открыли marina-residences.offplan.online — sales-app live.

Почему это критично для запуска:

1. Self-serve становится действительно self-serve — admin UI не обязан быть идеален с первого дня. Студия с AI-навыками может всё сделать через Claude, обходя UI rough edges.
2. Целевая аудитория (рендер-студии) — технически продвинутые — они уже работают с Figma, скриптами, API. «Управляйте проектами через Claude» — это selling point.
3. Power-операции, которые сложны в UI, — тривиальны через MCP — bulk-обновления статусов, копирование настроек, отчёты по доступности — всё через диалог.
4. Внутренняя команда использует с Day 1 — Сергей и Рома управляют клиентскими аккаунтами через Claude Code, не логинясь в каждую студию вручную.
5. Позиционирование AI-native — конкуренты дают web UI; мы даём UI + MCP server. Раз студия интегрировала Claude в свой workflow с нашим MCP — стоимость переключения растёт.

Подход — две итерации

Итерация 1 (Стадия 1, цель: launch): Read-only MCP

• Простая реализация (только GET endpoints)
• Низкий риск (Claude не может ничего изменить)
• Уже даёт огромную ценность: queries, reports, ответы на вопросы агентов
• Время: ~1-2 недели если API хорошо документирован

Итерация 2 (Стадия 1 или 2, в зависимости от эстимейта): Read+write MCP

• Полная автоматизация (create / update / delete / upload)
• Требует careful scoping (изоляция tenant'ов через MCP, scoped tokens)
• Время: ~3-6 недель

Условие переноса в Стадию 2: Если эстимейт от Ильи >6 недель для read-only — переносим итерацию 2 в Стадию 2, оставляя read-only в Стадии 1.

1.3.1 — API audit + scope definition for MCP exposure

Приоритет: Критично · Отдел: Tech · ⏱ · ❓

Что это: Полный audit существующих API endpoints, определение какие из них exposить через MCP в первой итерации (read-only) и второй (read+write). Документация в формате tool-friendly.

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

• Audit existing API endpoints (как 4.1.2, но scope для MCP)
• Категоризация: read-only safe / read+write / admin-only / never-expose
• Документация: для каждого endpoint — name, description, parameters, return shape (для MCP tool definition)
• Identify gaps: какие операции часто нужны, но нет endpoint
• Authentication scope (см. 1.3.4)

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

• ❓ Какие endpoints в первую итерацию (top 10 для read-only)?
• ❓ Есть ли API endpoints, которые не должны быть exposed через MCP вообще (admin-only)?

Зависит от: — Блокирует: Фазы 1.3.2, 1.3.3

1.3.2 — MCP read-only wrapper (Iteration 1)

Приоритет: Критично · Отдел: Tech · ⏱

Что это: Первая итерация MCP server — read-only. Любой MCP-совместимый client (Claude Desktop, Cursor) может подключиться, запросить данные, получить ответы.

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

• MCP server (Node.js / Python — выбор Ильи)
• Tools для read-only операций: list_projects, get_project, list_units, get_unit, list_buildings, get_availability, list_team_members и т.д.
• Authentication: per-studio token, scoped to single tenant
• Rate limiting (отдельно от human API)
• Logs: что AI запрашивает, для security audit
• Hosting: отдельный subdomain mcp.offplan.online или часть основного API

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

• Hosting: standalone server vs middleware на основном API?
• Token issuance: studio-admin генерит сам, или per-user?

Зависит от: Фаза 1.3.1 Блокирует: Фазу 1.3.3

1.3.3 — MCP read+write wrapper (Iteration 2)

Приоритет: Критично-Высокий (зависит от эстимейта) · Отдел: Tech · ⏱ · ❓

Conditional: Если эстимейт от Ильи >6 недель — переносим в Стадию 2. Read-only остаётся в Стадии 1 (1.3.2).

Что это: Вторая итерация — Claude может создавать проекты, обновлять unit'ы, менять статусы, загружать ассеты. Полный admin power через диалог.

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

• Tools для write-операций: create_project, update_unit, set_unit_status, upload_floor_plan, create_team_invite, update_pricing и т.д.
• Permission checks per tool (учитывает 5-level access из 1.2.7)
• Idempotency для write-операций (защита от повторных вызовов)
• Audit log per write-операция (см. 3.3.3)
• Confirmation flow для destructive операций (delete project требует подтверждения)
• Bulk-operations API (важно для use case «обнови статусы 40 юнитов»)
• Streaming progress для long operations (upload, processing)

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

• ❓ Эстимейт от Ильи — определяет где остаётся (Стадия 1 vs 2)
• Confirmation для destructive: текстовое подтверждение Claude'у или second factor?
• Bulk-операции: одна tool с массивом или итерация Claude-side?

Зависит от: Фаза 1.3.2 (read-only работает) Блокирует: —

1.3.4 — Authentication + scoped tokens

Приоритет: Критично · Отдел: Tech + Security · ⏱

Что это: Безопасная аутентификация для MCP. Token для конкретной студии, ограниченный по permissions, ротируемый.

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

• Token issuance UI в admin (studio admin генерит per-MCP-client token)
• Scope: read-only / read+write, optional per-project scope
• Rotation: можно отозвать, перевыпустить
• Expiration: настраиваемая (дни / месяцы / never)
• Storage on user side: Claude Desktop config / Cursor settings
• Logging: каждый MCP-call с token id (для аудита и rate limiting)
• Brute-force protection (rate limit, unusual patterns alerts)

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

• Token format: JWT / opaque / OAuth2?
• Refresh tokens или просто long-lived tokens с rotation?

Зависит от: Фаза 1.7.1 (tenant isolation), 1.2.7 (permission model) Блокирует: Фазы 1.3.2, 1.3.3

1.3.5 — Documentation + integration examples

Приоритет: Высокий · Отдел: Tech + Marketing · ⏱

Что это: Документация для разработчиков и студий — как подключить наш MCP server к Claude Desktop, Cursor, другим MCP clients.

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

• Quickstart guide: «Подключи offplan.online к Claude за 5 минут»
• Setup для Claude Desktop (config.json)
• Setup для Cursor / другие MCP clients
• 10 примеров запросов: «list available 2BR units», «show me sales report for last month», «update unit status», «create new project»
• Video walkthrough (Loom)
• Best practices: что НЕ нужно делать (например, не давать токен с write правами в shared environment)
• Troubleshooting

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

• Hosted docs vs README на GitHub?
• Public examples repo с типичными scripts/prompts?

Зависит от: Фазы 1.3.2, 1.3.4 Блокирует: —

Фаза 1.4 — Admin UX Critical Blockers

🟡 Понижен в приоритете (ревизия 2026-04-27): По мнению Сергея — большинство багов из UX-аудита воспроизводятся только на dev-окружении. Перед началом работ — верификация Ильёй и tech team: какие баги реально на проде, какие dev-only. Без этой верификации фаза остаётся в Стадии 1, но не блокирует приоритеты #1-3 (Visual, Onboarding, MCP).

Прямой результат UX-аудита (CONV-7, 2026-04-23) + заметок Сергея из ручного тестирования. Это баги, которые будут блокировать студий в первую неделю.

1.4.1 — Data scoping bugs (Units=0, Tower 1 dropdown, compass)

Приоритет: Критично · Отдел: Tech · ⏱ · 🔬

Что это: Набор связанных багов scoping, когда данные показываются не в той области где студия их ищет или пропадают при определённых условиях.

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

• Units page показывает 0 записей при наличии 5 (scoping по building) → добавить building selector или показывать все units с колонкой building
• Tower 1 пропадает из dropdown — нужна регрессия (🔬 проверить на проде, возможно только dev-баг)
• Compass feature меняет количество видимых towers — разобраться в логике (🔬 проверить на проде)
• Unit создан но не виден в списке — dashboard говорит 5, в /units пусто (🔬 проверить на проде)
• Автоматические тесты на каждый scoping case чтобы не вернулось

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

• Все 4 бага повторяются на проде или только на dev?
• Связаны ли они между собой архитектурно?

Зависит от: — Блокирует: Фазу 2.1 (пилот-студии сразу встретят эти баги, если они на проде)

1.4.2 — Form reliability (React wipes, validation reset, unit number uniqueness)

Приоритет: Критично · Отдел: Tech + QA · ⏱ · 🔬

Что это: Формы работают непредсказуемо: ввёл-сохранил-пропало, ошибка валидации стирает всю работу, уникальность проверяется криво.

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

• React re-render wipes text inputs при изменении dropdown — переписать state management формы (исправить мутацию state через controlled components, useRef или form library)
• Form validation НЕ сбрасывает прогресс при error (🔬 проверить на проде) — либо inline валидация без submit, либо сохранение state между submit'ами
• Unit number uniqueness: если сменил 7→8, то 7 должен освободиться (🔬 проверить на проде) — проверить query логику
• Sticky error messages (не исчезают через 2 секунды)
• Автотесты на form reliability в Playwright (CI)

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

• Используется ли form library (react-hook-form / formik) или raw useState?
• Готовы ли переписать form architecture или только точечные fix?

Зависит от: — Блокирует: Фазу 1.4.3 (создание проекта требует рабочих форм)

1.4.3 — Navigation + project creation path

Приоритет: Критично · Отдел: Tech + Design · ⏱ · 🔬

Что это: Студия не может сама создать проект, нет breadcrumbs / контекста, /levels ведёт в /views.

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

• UI для создания нового проекта (self-serve path — сейчас отсутствует)
• Fix routing: /levels → /levels (не /views) — переименовать route или sidebar label
• Breadcrumbs на всех section pages: «Studio > Project > Building > Section»
• Контекст здания в header (сейчас на Floor Plans пишет «1 Plan» без указания билдинга)
• Post-save navigation при создании building: не прыгать на другой проект (🔬 проверить на проде)
• Project switcher — явно видимый, с «+ Create new project»

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

• Совместим ли project creation UI с multi-tenant ограничениями (лимиты по плану)?

Зависит от: Фаза 1.4.2 Блокирует: Фазу 1.2.4 (wizard нужен рабочий flow создания)

1.4.4 — Asset upload clarity (formats, sizes, PDF, preview)

Приоритет: Критично → возможно отпадает · Отдел: Tech + Design · ⏱

Дополнение (ревизия 2026-04-27): Tech team уже работает над backend-инфраструктурой, которая авто-обрабатывает любые форматы (PDF / HEIC / etc.). Если Илья подтвердит готовность — эта sub-phase может стать неактуальной. Дождаться апдейта.

Что это: Сейчас неясно что можно загружать: PDF молча отвергается, размеры скрыты, форматы не указаны, preview нет.

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

• Inline hints на upload field: «JPEG, PNG, WebP, до 5 MB» — прямо рядом с кнопкой
• Для floor plates: «PDF не поддерживается — конвертируйте в PNG (белый фон, ≤100 KB)»
• Для panorama: «Spherical 360° JPEG, 2:1 aspect, рекомендуемое разрешение 4096×2048»
• Для welcome video: показать size limit явно (сейчас скрыт)
• PDF upload не должен silent fail — явное сообщение «PDF не поддерживается»
• Click-to-preview на uploaded изображения (открывается modal/lightbox)
• Сразу видеть thumbnail после загрузки

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

• Все лимиты по форматам/размерам известны команде? Если нет — нужен audit
• Планируем ли добавить PDF-конвертер (в Фазе 4.5)?

Зависит от: — Блокирует: Фазу 1.4.6

1.4.5 — Display caps & pagination (Buildings ~10)

Приоритет: Критично · Отдел: Tech · ⏱

Что это: Buildings список cap'ится примерно на 10 записях, 11-е не видно. У студий с большими проектами это блокер с первого дня.

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

• Pagination на Buildings, Units, Floor Plans, Galleries (любая list page где возможно >10 записей)
• Infinite scroll или classic pagination (UX decision)
• Показать total count («Showing 1-10 of 47»)
• Server-side pagination (не грузить все записи на клиент)
• Search + pagination работают вместе

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

• Infinite scroll vs classic — что лучше подходит для данного use case?
• Какие page sizes (10/25/50) предлагать?

Зависит от: — Блокирует: —

1.4.6 — Preview + sticky validation UX

Приоритет: Высокий · Отдел: Tech + Design · ⏱

Что это: UX-улучшения поверх критичных блокеров — click-to-enlarge на images, valid validation feedback, предотвращение accidental loss.

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

• Click-to-enlarge на всех uploaded images
• «Unsaved changes» warning при попытке покинуть страницу
• Inline field validation (не ждать submit)
• Успешное сохранение — чёткий visual feedback (не просто toast на 1 секунду)
• Drag-and-drop upload с visual drop zone

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

• Нужны ли Cmd+S shortcuts для power users?

Зависит от: Фаза 1.4.4 Блокирует: —

Фаза 1.5 — Платёжная инфраструктура + Sales Page

Студия должна пройти signup → trial → подписка полностью сама. Плюс публичная страница, которая продаёт.

Дополнение (ревизия 2026-04-27, фидбек Надежды): Помимо месячной подписки, нужен flat-fee tier — оплата за настройку проекта + SLA на новые проекты. Многие клиенты делают проект, запускают, и не хотят платить ежемесячно если контент почти не меняется. См. новую sub-phase 1.5.8.

1.5.1 — Landing page

Приоритет: Критично · Отдел: Marketing + Design · ⏱

Что это: Публичная страница offplan.online, которая конвертирует посетителя в trial signup.

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

• Hero: главный месседж + CTA «Start free trial — 3 months free»
• Ценностное предложение: 360° walkthroughs, floor plans, unit list, inline-редактирование (roadmap)
• Кейс-стади с цифрами (реальный клиент — после подтверждения можно опубликовать)
• Сравнение с конкурентами (Matterport, Kuula) — честное: «где мы лучше, где хуже»
• Тарифные планы (prices, limits, features) — таблица
• FAQ (10-15 типовых вопросов)
• Testimonials (заполняется после первых пилотных студий)
• CTA в нескольких местах
• Footer с Legal linkами (ToS, Privacy, DPA)

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

• Используем ли существующий VV-сайт как базу или делаем с нуля?
• На каком стеке (Webflow / Framer / custom Next.js)?

Зависит от: Фаза 1.5.2 (нужна pricing) Блокирует: —

1.5.2 — Pricing plans

Приоритет: Критично · Отдел: Product · ❓

Что это: Определить структуру тарифов для запуска. В Фазе 4.2 будет оптимизация — сейчас нужна базовая работающая структура.

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

• 2-3 тарифа максимум (сложнее → хуже конверсия)
• Предварительная структура из v2:
  • Starter ~$99/мес: 3 проекта, 1 пользователь, базовые фичи
  • Studio ~$299/мес: 10 проектов, 5 пользователей, Walkthroughs, Analytics
  • Agency ~$699/мес: Unlimited, API, Priority support
  • Enterprise: custom
• Trial: 3 месяца free без карты (как договорено в v2)
• Annual discount (пока отложить — в Фазу 4.2)

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

• ❓ Финальная цена и лимиты каждого плана
• ❓ Trial без карты vs с картой (без карты → больше signup, с картой → лучше конверсия)
• ❓ По проектам / по рендерам / по seats — какая метрика лимита?

Зависит от: — Блокирует: Фаза 1.5.1

1.5.3 — Payment integration (Stripe vs Paddle)

Приоритет: Критично · Отдел: Tech + Legal · ⏱ · ❓

Что это: Платёжный провайдер + webhook-активация подписок.

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

• Решение: Stripe или Paddle
  • Stripe: больше контроля, ниже комиссии, но EU VAT сами платим
  • Paddle: дороже, но Merchant of Record (EU VAT на себе), проще юридически
• Subscribe flow (card capture или delayed-card trial)
• Webhook handler: subscription.created → активация tenant, subscription.deleted → downgrade/block
• Retry logic для failed payments (базовый — dunning в Фазе 4.2)
• Test mode для staging
• PCI compliance: никогда не видим номер карты (через Checkout или Elements)

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

• ❓ Stripe vs Paddle — требует решения до начала работы
• Есть ли у VV существующий Stripe/Paddle аккаунт или заводим с нуля?

Зависит от: Фаза 1.5.2 Блокирует: Фазу 1.5.4

1.5.4 — Self-service billing UI

Приоритет: Критично · Отдел: Tech + Design · ⏱

Что это: В админке студия сама управляет своей подпиской.

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

• Страница «Billing» в admin
• Текущий план + что он включает
• Следующая дата списания + сумма
• Сменить план (upgrade / downgrade) с расчётом proration
• Скачать invoice (PDF) — за любой период
• Отмена подписки (grace period до конца оплаченного периода)
• Обновить способ оплаты
• История платежей

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

• Что происходит при отмене: read-only access или полный block?

Зависит от: Фаза 1.5.3 Блокирует: —

1.5.5 — Trial mechanics

Приоритет: Критично · Отдел: Product + Tech · ❓

Что это: Как работает 3-месячный trial — активация, limits, истечение.

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

• Активация автоматом при signup (без карты?)
• Лимиты в trial: те же что в Starter или урезанные?
• Банер «X дней до конца trial» в админке
• Email reminders: за 14 дней, 7, 3, 1 до истечения
• Поведение при истечении: block / read-only / downgrade
• Возможность продлить trial (кто решает — админы VV ручно?)

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

• ❓ Без карты (выше signup, больше абуза) vs с картой (ниже signup, выше конверсия)
• ❓ Block vs read-only по истечении trial без оплаты

Зависит от: Фазы 1.5.3, 1.5.4 Блокирует: —

1.5.6 — Webhook activation/deactivation

Приоритет: Критично · Отдел: Tech · ⏱

Что это: Надёжная обработка событий от платёжного провайдера.

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

• Idempotent handler (webhook может прийти дважды)
• Retry logic если наш endpoint упал (Stripe/Paddle ретрают сами, но логика нужна)
• Signature verification (Stripe webhook secret)
• Обработка всех критичных событий:
  • subscription.created → активация
  • invoice.payment_succeeded → продление
  • invoice.payment_failed → dunning trigger
  • subscription.deleted → downgrade/block
  • customer.updated → синхронизация
• Logging каждого webhook для аудита

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

• Queue (RabbitMQ / SQS) или прямой handler? (для reliability)

Зависит от: Фаза 1.5.3 Блокирует: —

1.5.7 — Billing edge cases (refunds / chargebacks / FX / tax invoices)

Приоритет: Критично · Отдел: Tech + Legal + Finance · ⏱ · ❓

Что это: Набор edge-case сценариев биллинга, которые нельзя игнорировать — refunds, chargebacks, multi-currency, tax-compliant invoicing (UAE TRN, EU VAT). Эти сценарии появляются сразу как только студия платит первый инвойс.

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

• Refund policy: под каким условием refund возможен (14 дней cooling-off EU / pro-rata если downgrade / никогда)
• Refund flow: UI для запроса (self-serve или ticket?), approval workflow, Stripe/Paddle API integration
• Chargeback handling: Stripe webhook charge.dispute.created → auto-freeze account? Notification → product team → evidence submission (до 21 дня)
• Currency handling: plan prices в одной valute ($ / €) или multi-currency? FX conversion (заморозить rate на момент sign-up vs текущий)
• Tax invoices:
  • UAE TRN (Tax Registration Number) на invoice для UAE-клиентов
  • EU VAT с reverse charge для B2B
  • US Sales Tax (если попадём на нужный нексус)
  • Tax-compliant format per country
• Invoice numbering: sequential, compliant с local tax regulations
• Credit notes для refunds (формально — не просто возврат)

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

• ❓ Refund policy — 14 дней / pro-rata / never / case-by-case?
• ❓ Single currency ($) или multi-currency ($ / € / AED)?
• ❓ При chargeback — auto-freeze или wait-and-see?
• Tax engine — Stripe Tax / Avalara / Paddle handles (если Paddle)?

Зависит от: Фаза 1.5.3 (payment integration) Блокирует: Стадию 2 (если студия заплатит и потом попросит refund — процесс должен быть готов)

1.5.8 — Flat-fee pricing tier (NEW — фидбек Надежды 2026-04-23)

Приоритет: Высокий · Отдел: Product + Tech + Finance · ⏱ · ❓

Что это: Альтернатива subscription — модель «оплата за настройку проекта + SLA». Возникла из звонка с Надеждой (Dubai sales manager): её сценарий — настроили проект один раз, контент почти не меняется, продажи идут с того что залито. Платить ежемесячно за продукт, который «просто крутится» — клиент не хочет.

Сценарий клиента (Надежда):

1. Студия покупает «настройку проекта» (one-time fee)
2. Студия / VV настраивает проект на платформе (drag-and-drop, ~2 часа работы)
3. Проект работает self-service
4. Если нужны изменения — отдельный SLA: за фиксированную плату на новые проекты или за час работы на изменения существующих
5. Никакой ежемесячной подписки

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

• Tier «Project-based» в pricing structure (рядом со Starter / Studio / Agency / Enterprise)
• One-time setup fee per проект (с лимитом изменений в месяц)
• SLA-tier: оплата за новые проекты + час работы для изменений (отдельный billing channel)
• Технически: subscription и flat-fee — разные billing flows в Stripe/Paddle (subscription vs invoice)
• В админке: tab «Project subscriptions» (per project) vs «Studio subscription» (общая)
• Решить: можно ли смешивать (одна студия с подпиской и flat-fee проектами)?

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

• ❓ Цена per проект (one-time): зависит от размера (юнитов / зданий)?
• ❓ Что включается в setup fee: количество правок, поддержка?
• ❓ SLA pricing: per-hour, per-incident, monthly retainer?
• ❓ Как студия / VV выбирает model в момент signup или per project?

Зависит от: Фазы 1.5.2 (pricing structure), 1.5.3 (payment integration) Блокирует: —

Фаза 1.6 — Legal & Compliance

Без этого не можем легально продавать в EU и UAE/GCC. Юридические тексты пишет юрист — мы формулируем требования.

1.6.1 — Terms of Service

Приоритет: Критично · Отдел: Legal

Что это: Основной договор между VV и студией. Защищает от проблемных клиентов и кейсов.

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

• 3-уровневая структура: VV (платформа) / студия (subscriber) / девелопер или покупатель (end user)
• Liability cap: 12 месяцев оплаты подписки
• Intellectual property: VV владеет платформой, студия своим контентом
• Termination: grace period 30 дней → suspend → удаление через 90 дней
• Acceptable Use Policy: запрет спама, malware, illegal content
• SLA: 99.5% uptime (чтобы связывалось с Фазой 1.7.3/1.7.4)
• Dispute resolution + arbitration jurisdiction
• Change of terms policy (notification + opt-out)

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

• Юрисдикция: UAE / EU / UK?
• Нужен ли UAE-specific договор отдельно?

Зависит от: Фаза 1.6.5 (юрисдикция) Блокирует: Стадию 2 (студии подписывают ToS)

1.6.2 — Privacy Policy

Приоритет: Критично · Отдел: Legal

Что это: Как мы обрабатываем персональные данные студий и их конечных пользователей. GDPR + UAE DPR.

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

• 2-уровневая структура данных: VV — контроллер данных студий; студии — контроллеры данных своих клиентов
• Lawful basis per category: договор (биллинг), легитимный интерес (аналитика), согласие (маркетинг)
• Retention: активный аккаунт / 90 дней после cancel / логи 12 месяцев
• Права субъектов: access, erasure, portability, right to object, right to restrict
• Data transfer: EU → UAE (нужны SCCs или adequacy)
• Sub-processors list (актуализируется)
• Breach notification process (72 часа GDPR)

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

• Где хранить данные (регион)?
• Нужен ли DPO (Data Protection Officer)?

Зависит от: Фаза 1.6.5 Блокирует: Фазу 1.6.3

1.6.3 — Data Processing Agreement (DPA)

Приоритет: Критично · Отдел: Legal

Что это: GDPR Art. 28 требует DPA между controller (студия) и processor (VV). Без DPA студия технически нарушает GDPR используя нас.

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

• Покрывает: категории данных, цели обработки, сроки хранения, locations
• Sub-processors: Stripe, Hotjar/Clarity, email provider, CDN, error tracking (актуализируется)
• Security measures: ссылки на Фазу 1.7 (tenant isolation, encryption, backups)
• Audit rights студии
• Breach notification terms (VV → студия)
• Sub-processor changes: notice period, opt-out right

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

• Self-serve DPA (клик «принимаю») vs signed agreement (per студия)?
• Шаблон через Termly / iubenda vs custom by EU GDPR-юрист?

Зависит от: Фазы 1.7.1, 1.6.2 Блокирует: Стадию 2

1.6.4 — Cookie consent

Приоритет: Критично · Отдел: Legal + Tech · ⏱

Что это: Banner на публичных страницах + в admin перед загрузкой analytics/marketing cookies.

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

• Banner перед первой загрузкой Hotjar/Clarity/GA
• Категории: necessary / analytics / marketing
• Reject all / Accept all / Customize — явные опции
• Consent logged для аудита (GDPR требует доказывать consent)
• Работает как в admin, так и на публичных страницах проектов
• Готовое решение (Cookiebot / OneTrust / Cookieyes) vs custom

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

• Готовое решение vs custom — стоимость vs flexibility?

Зависит от: Фаза 1.6.2 Блокирует: Фазу 2.4 (analytics tools нужны в пилоте)

1.6.5 — Jurisdiction & EU Representative

Приоритет: Критично · Отдел: Legal · ❓

Что это: Юридическое лицо + GDPR EU Representative (если VV UAE-юрлицо работает с EU-пользователями).

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

• Решение о структуре: EU Rep vs EU-юрлицо
  • EU Rep (GDPR Art. 27): дёшево ($50-200/мес), но только номинал
  • EU-юрлицо (Ireland / Estonia / Malta): дороже в поддержке, но полноценный договор
• VAT registration threshold — где и когда регаемся
• Tax jurisdiction (где платим corporate tax)
• Bank account для EU transactions (если EU-юрлицо)

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

• ❓ EU Rep vs EU-юрлицо — требует решения Сергея + юриста
• ❓ Страна (Ireland / Estonia e-Residency / Malta)?

Зависит от: — Блокирует: Фазы 1.6.1, 1.6.2, 1.5.3

1.6.6 — VAT registration

Приоритет: Высокий · Отдел: Legal + Finance · ❓

Что это: Регистрация по VAT там где нужно (EU, UK, UAE).

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

• EU VAT для B2B с reverse charge механизмом
• UK VAT если планируем серьёзные продажи в UK
• UAE VAT (5%) для локальных продаж
• Если Paddle выбран как MoR — они берут на себя большую часть
• Invoice template с нужными полями per юрисдикция

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

• ❓ Реалистичная география первого года (EU-only / +GCC / global)?

Зависит от: Фаза 1.6.5 Блокирует: —

Фаза 1.1 — Admin Visual Redesign + Branding (Priority #1)

🔴 Priority #1 (ревизия 2026-04-27): Брендбук + визуальный язык — фундамент всей последующей работы. Без этого админка выглядит cheap для первых студий, и каждое последующее визуальное изменение придётся переделывать. Сергей: «Это база для всех следующих визуальных задач.»

Выровнять визуальный язык и information architecture админки с концепцией v4 mockup — добавить informational блоки, progress indicator для онбординга, обновить палитру до premium-уровня. Детальная концепция и визуальный референс: Visual Appendix v3.

Дополнительно (по итогам разговора с Ромой 2026-04-24): брендбук создаётся через Claude Design + Figma (получена от Ромы). Это меняет процесс — не дизайнер вручную, а итеративная работа с AI на основе существующих визуальных решений + reference. Output: цветовая палитра, typography, button styles, component direction.

1.1.1 — Informational blocks (contextual help)

Приоритет: Критично · Отдел: Design+Tech · ⏱

Что это: Добавить контекстные info-блоки «Heads up» на каждой секции admin — объясняют что сделать, в каком порядке, какие форматы/размеры принимаются, где типичные ошибки. Снимает большую часть onboarding friction: студия понимает что делать без обращения в поддержку. См. визуальный пример в Visual Appendix (Wizard body section).

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

• Info-блоки на каждой ключевой секции admin (Buildings, Levels, Floor Plates, Floor Plans, Units, Panoramas, Hotspots, Branding)
• Content: порядок действий, формат файлов, размеры, ссылки на KB
• Стиль callout — sand palette с золотой левой полосой (как в mockup)
• Dismissable: можно свернуть per user / per project для power-users
• Контент-writer готовит тексты (~2-3 предложения на секцию + ссылка на детальный guide)
• Testing: первые пилот-студии не должны спрашивать «а куда идти дальше»

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

• Кто пишет содержание info-блоков (Content team / product team)?
• Динамический контент (reacts to empty state) или статика?

Зависит от: Фаза 1.4.3 Блокирует: —

1.1.2 — Progress indicator in sidebar (numbered wizard)

Приоритет: Критично · Отдел: Design+Tech · ⏱

Что это: Встроить numbered wizard 1→10 прямо в sidebar — студия всегда видит «где я сейчас» и «что дальше» по шагам настройки проекта. Решает главный UX gap из аудита — отсутствие порядка действий. См. Visual Appendix — Numbered Wizard.

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

• 10 шагов в sidebar: Theme → Features → Labels & Terms → Buildings → Levels → Floor Plates → Floor Plans → Units → Panoramas → Hotspots
• Состояния каждого шага: done (галочка, green), active (голд outline + fill), upcoming (серый number)
• Хранение progress per project (не per user) — переключение проектов показывает правильный статус
• Клик на любой шаг → навигация к соответствующей секции admin
• Визуальная палитра: sand/gold/navy (консистентно с Visual Appendix v4 mockup)
• Автоматическая детекция «шаг выполнен» (есть хотя бы 1 entity в секции) или manual mark?
• Collapsible sidebar (mobile + power-users могут скрыть wizard)

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

• Auto-detect completion или manual mark done?
• Поведение если студия прыгает между шагами вне порядка?
• Показывать ли wizard после завершения всех 10 шагов, или скрыть?

Зависит от: Фаза 1.2.4 (onboarding wizard) Блокирует: —

1.1.3 — Visual language refresh (palette + typography)

Приоритет: Высокий · Отдел: Design · ⏱

Что это: Минимальный refresh визуального языка до пилота — убрать «cheap-looking» traffic-light dots и заменить на sand/gold status tags как в v4 mockup. Это не полный редизайн (тот в Фазе 4.3), а pre-pilot upgrade чтобы admin выглядел premium для первых студий. Полный вижуал: Visual Appendix — Палитра.

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

• Status indicators: available / reserved / sold — переход с яркой светофорной точки на мягкий tag (sand background + subtle color bar)
• Акцент-цвета: gold вместо неоновых green/red в primary actions
• Typography audit: font-size consistency, letter-spacing, heading hierarchy
• Spacing / padding consistency по всем секциям
• Component library: унифицировать кнопки, карточки, input'ы
• Icons: пройтись по текущим иконкам, заменить cheap / inconsistent на единый набор (Phosphor / Lucide / Heroicons)

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

• Дизайнер для refresh — внутренний или подрядчик?
• Iconset: какой выбираем (Phosphor / Lucide / Heroicons / custom)?

Зависит от: — Блокирует: —

Фаза 1.8 — Sales-app UX redesign (NEW — фидбек Надежды 2026-04-23)

🟠 Critical-conditional (ревизия 2026-04-27): Фаза добавлена по итогам видео-звонка с Надеждой (Dubai sales manager). Описанные изменения — архитектурные, потенциально требуют значительного времени. Если эстимейт от Ильи большой → переносим часть в Стадию 2 или 3. В Стадии 1 на минимум — фильтр-based выбор юнитов (1.8.1) как MVP, остальное может быть отложено.

Подтверждение Ромы: «Это не первый раз мы это слышим. Нужно было приоритизировать раньше.» Multi-source validation, не одного клиента мнение.

Контекст (из видео-звонка с Надеждой)

Проблема текущего флоу: Сейчас студия → здание (фасад) → клик на хотспоты квартир → юнит. Это работает на маленьких проектах, но:

• В проекте Надежды: 22 квартиры на этаже, типы меняются каждые 4 этажа
• 300+ юнитов = 300+ хотспотов = хаос
• Люди не выбирают квартиру по тому где она на фасаде — они выбирают по типу, площади, виду, цене

Правильный флоу (из звонка):

1. Заходишь в проект → красивый лендинг (видео, 360°, галерея, виды)
2. Клик «Apartments» / «Floor Plans»
3. Фильтры: bedrooms (1BR / 2BR / 3BR / penthouse) + view direction (на море / город / парк) + price range + ориентация
4. Показываются только подходящие floor plans
5. Клик floor plan → вертикальный stack: все юниты этого типа на всех этажах, как меняется цена и вид по этажам
6. Выбираешь конкретный юнит

Два сценария покупателя (от Надежды):

• Сценарий A: «Хочу 2BR» → видит все типы 2BR, сравнивает площади, видит как цена меняется с этажом и видом → выбирает приемлемый вариант
• Сценарий B: «Бюджет $X» → фильтрует по цене → видит что попадает в бюджет → выбирает лучший вариант

1.8.1 — Filter-based unit selection (MVP)

Приоритет: Критично · Отдел: Tech + Design · ⏱ · ❓

MVP — должно остаться в Стадии 1 даже если остальные подзадачи переносятся. Минимум: фильтр по bedrooms + view direction + price + статус. Без этого современный sales-app не работает на больших проектах.

Что это: Filter-based выбор юнитов вместо хотспотов. Покупатель фильтрует по параметрам, видит подходящие варианты, выбирает.

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

• Расширить существующий filter-component (сейчас только статусы): добавить bedrooms, view direction, price range, ориентация
• Filter UI: чекбоксы / sliders / dropdown — на боковой панели или в header
• Показывать только подходящие floor plans / units
• Counter: «X юнитов соответствуют фильтру»
• URL-параметры (shareable links: ?br=2&view=sea&price=1-2M)
• Reset filters
• Empty state: «нет подходящих» + suggest relaxing filter

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

• ❓ Эстимейт от Ильи — насколько готов текущий filter-component к расширению?
• Какие фильтры показывать по умолчанию vs скрытые в "more filters"?

Зависит от: — Блокирует: —

1.8.2 — Floor plan → vertical unit stack view

Приоритет: Высокий · Отдел: Tech + Design · ⏱ · ❓

Если сложно — переносим в Стадию 2.

Что это: Когда пользователь выбрал тип floor plan, показать вертикальный стек: все юниты этого типа на всех этажах, как цена и вид меняется по высоте.

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

• Stack visualization: список юнитов одного типа, отсортированный по этажу (high to low)
• Per-unit info: floor number, price, view, status, area
• Дополнительно: сравнение по этажам (например, slider «slide up/down»)
• Click на юнит → unit detail page (existing)
• Альтернативный view: «show on floor plate» (где этот юнит на этажном плане) — secondary

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

• Visualization: list vs visual stack (вертикальная башня)?
• Производительность для 50+ floors?

Зависит от: Фаза 1.8.1 Блокирует: —

1.8.3 — Per-project status visibility toggle

Приоритет: Критично · Отдел: Tech + Design · ⏱

Что это: Каждый проект может настроить, показывать или скрывать статусы юнитов (Available / Reserved / Sold). Некоторые девелоперы не хотят публично показывать sold-out (early-stage sales, prestige). Сейчас статусы хардкод — Надежда заплатила $12k чтобы их скрыть на одном проекте.

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

• Project setting: «Show unit statuses» (yes/no/partial)
• Если no — статусы скрыты на: building view, floor plate, unit list, unit detail
• Если partial — настраиваемо: показывать Available, скрывать Reserved/Sold
• Custom labels per project: «Available» → «Inquire», «Sold» → ничего, и т.д.
• Default: показывать (статус-кво для большинства)

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

• Granular: per-status custom labels или просто show/hide?
• Partial показывать «Inquire» или просто пустой статус?

Зависит от: — Блокирует: —

1.8.4 — Status indicators redesign (kill traffic-light colors)

Приоритет: Высокий · Отдел: Design + Tech · ⏱

Что это: Текущие яркие зелёные/жёлтые/красные «светофоры» на статусах — выглядят дёшево и слишком навязчиво. Заменить на нейтральные tags. Уже частично в плане как 1.1.3 (Visual language refresh), но здесь explicit для sales-app side.

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

• Заменить bright dots на subtle tags (sand background + lower-saturation accent)
• Убрать "светофор" green/yellow/red в принципе — в дефолте no color, в alternative — gold/sand палитра (см. 1.1.3)
• Per-project visibility (см. 1.8.3) и кастомизация stays

Зависит от: Фаза 1.1.3 (visual language refresh — общая палитра) Блокирует: —

1.8.5 — Window-based panoramic views

Приоритет: Средний-Высокий · Отдел: Tech + Content · ⏱ · ❓

Если сложно — переносим в Стадию 3. Опциональная фича, сильно усиливает sales pitch.

Что это: В floor plan можно кликнуть на конкретное окно — открывается 180°/270° панорамный вид из этого окна. Был в их Moscow-проекте, очень нравился клиентам. Сейчас в Abu Dhabi проекте отсутствует, Надежда сильно жалеет.

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

• В админке: для каждого юнита можно загрузить window-panoramas (180° для фасадных, 270° для угловых)
• В sales-app: на floor plan юнита окна — clickable
• Click → open panoramic viewer (existing 360° tech возможно reuse'нуть)
• Mobile-friendly (тач-управление)
• Pre-loading для smooth UX

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

• ❓ Контент-pipeline: как студия делает window panoramas? (renders / camera positions)
• Технически: 180°/270° viewer существует в текущей платформе или нужно с нуля?

Зависит от: Фаза 1.8.1, 1.8.2 Блокирует: —

1.8.6 — Currency + units toggle (USD/AED, sqm/sqft)

Приоритет: Высокий · Отдел: Tech + Design · ⏱

Что это: Toggle для валюты и единиц измерения — особенно критично для Dubai (часть рынка думает в sqft, часть в sqm; цены в USD vs AED).

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

• Header toggle: USD / AED (или другие per project)
• Header toggle: sqm / sqft
• Selection persists в session / localStorage
• Pricing API возвращает primary + conversion rates
• Sqm/sqft автоматический расчёт (фикс factor)
• Project setting: какие currencies доступны (одна / несколько)
• FX rates: захардкодить или live API?

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

• ❓ FX rates: snapshot per project (зафиксирован) vs live (обновляется ежедневно)?
• Default: какая валюта дефолтная — based on user IP / project setting?

Зависит от: — Блокирует: —

Связи с другими фазами

• 4.5.1 (Compare units) — связано: filter-based UX делает compare более ценным. Возможно подтягиваем 4.5.1 в Стадию 2.
• 3.3.3 (Audit log) — sales presentations в admin (для CRM integration) логгируются здесь
• CRM integration depth (новое для backlog): во время разговора Надежды описана глубокая CRM-интеграция (Microsoft Dynamics) — отслеживать какие юниты показывались каким клиентам. Илья оценил в ~$100k. Не Стадия 1, но data model для "presentation events" нужно проектировать заранее. Добавить в backlog для Стадии 2.

Зависимость от внешних ресурсов

Что нужно от tech team (Илья):

• Эстимейт по 1.8.1, 1.8.2, 1.8.3 (минимум для решения «Стадия 1 или 2»)
• Архитектурный feasibility: насколько готова текущая архитектура к filter-based флоу

Что нужно от content team / Ромы:

• Полный обзор Nadezhda call (Сергей сделано — этот документ)
• Разговор с другими sales managers для validation

Стадия 2 — Пилотный запуск со студиями

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

Две под-стадии внутри пилота

Переход Alpha → Pilot: условие — первые 3-5 студий прошли путь «signup → первый проект published» без критичных блокеров. Только после этого приглашаем полные 20.

Условие выхода из стадии: есть ~100 живых проектов (5 проектов × 20 студий), weekly feedback показывает стабильную работу, критичные и high-priority баги закрыты, команда готова к публичному open doors.

Фаза 2.1 — Дизайн пилотной программы

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

2.1.1 — Отбор 20 студий (критерии + outreach)

Приоритет: Критично · Отдел: Sales + Product · ⏱

Что это: Критерии отбора + конкретный список из 20 студий готовых к пилоту.

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

• Критерии отбора: география (разные рынки), размер (разные портфели), специализация (residential / commercial)
• Long-list 50+ из существующих контактов VV
• Outreach: personalized email + демо-звонок
• Short-list 20 с подписанным NDA и коммитментом на weekly feedback
• Резерв 10 дополнительных на случай отвалов

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

• Есть ли существующий CRM с потенциальными пилот-студиями?
• Кто делает outreach (Project Lead / Product team / Sales-подрядчик)?

Зависит от: — Блокирует: —

2.1.2 — Условия пилотной программы + NDA

Приоритет: Критично · Отдел: Legal + Product

Что это: Формальные условия участия, защищающие обе стороны.

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

• Срок пилота: 3 месяца (с возможностью продления)
• Бесплатный доступ в обмен на weekly feedback + разрешение на case study / testimonial
• NDA о функциях продукта до публичного запуска
• Commitment: еженедельный 30-минутный звонок с нами
• Что происходит после пилота: автоматически продление по оплате / отмена / migrate на paid

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

• Кейс-стади — opt-in или default?
• Право студии забрать свой контент после пилота (экспорт)?

Зависит от: Фаза 1.6.1 (Terms of Service) Блокирует: Фазу 2.1.1

2.1.3 — Коммуникационный канал + cadence

Приоритет: Высокий · Отдел: Product + Ops

Что это: Где и как общаемся с пилот-студиями в течение 3 месяцев.

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

• Dedicated Slack channel / WhatsApp group / Telegram group (выбрать один)
• Weekly 30-minute check-in call (группа из 4-5 студий за раз или 1-on-1?)
• Monthly demo call: новые фичи + Q&A
• Shared roadmap public view (read-only) — студии видят что мы делаем по их фидбеку
• Dedicated Customer Success (Project Lead изначально, потом может быть отдельный человек)

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

• Slack vs WhatsApp — что удобнее студиям?
• Групповые vs 1-on-1 calls?

Зависит от: — Блокирует: —

2.1.4 — Pilot-specific documentation

Приоритет: Высокий · Отдел: Content + Product

Что это: Приватная документация для пилот-студий — не то же что публичная KB.

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

• «Welcome to the pilot» guide (что можно/нельзя публично говорить)
• Known issues page (актуализируется) — чтобы студии не репортили одно и то же
• Roadmap (что ожидается когда)
• Contact tree (кого пинговать по какому вопросу)
• Feedback submission guide (как репортить баги/идеи)

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

• На каком языке документы (EN / RU)?

Зависит от: — Блокирует: —

Фаза 2.2 — Инфраструктура онбординга студий

White-glove onboarding первых 20 — помогаем вручную, чтобы потом автоматизировать на основе реального опыта.

2.2.1 — Assisted onboarding (white-glove)

Приоритет: Критично · Отдел: Product + Ops · ⏱

Что это: Для первых 5-10 студий — 1-hour kick-off call где мы помогаем настроить домен, создать первый проект, залить первый contentt.

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

• 1-hour call скрипт (повторяемый)
• Pre-call checklist: что студия должна иметь готово (бренд-лого, первый проект, контент)
• Post-call checklist: что должно работать после звонка
• Recording (с разрешения) для внутреннего обучения
• Gradually reduce: 5 первых — 1 hour каждый; следующие 10 — 30 min; последние 5 — self-serve с async support
• Feedback: что было сложно, что стоит автоматизировать

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

• Кто проводит onboarding calls (Project Lead / отдельный CS)?

Зависит от: Фаза 1.2 (onboarding flow должен работать) Блокирует: —

2.2.2 — Fast-track support channel

Приоритет: Критично · Отдел: Ops · ⏱

Что это: Для пилот-студий — прямой канал с ответом <2 часа в рабочее время.

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

• Priority в чате (см. Фазу 2.3)
• Dedicated email/Slack channel для pilot
• SLA: <2 часа в рабочее время, <24 часа вне
• Escalation path: chat → engineer → tech team → product team
• Бaseline: сколько в среднем тикетов в день ожидаем (для capacity planning)

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

• Кто в on-call для пилота?

Зависит от: Фаза 2.3 Блокирует: —

2.2.3 — Onboarding content (Loom videos + written guides)

Приоритет: Высокий · Отдел: Content

Что это: Базовые гайды чтобы студия не обращалась за одним и тем же.

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

• Loom video: «Создание первого проекта за 15 минут» (3-5 минут)
• Loom video: «Загрузка panorama и hotspots»
• Loom video: «Подключение custom domain»
• Written guides для каждого видео (сопровождение)
• Embedded в admin (contextual: открывается в нужный момент)

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

• Кто делает видео (Product team / tech team / подрядчик)?

Зависит от: Фаза 1.2 Блокирует: —

Фаза 2.3 — Support Infrastructure

Инфраструктура поддержки, которая работает в пилоте и продолжает работать в публичном запуске.

2.3.1 — AI chat platform (выбор + интеграция)

Приоритет: Высокий · Отдел: Product + Ops · ⏱ · ❓

Что это: Основной канал поддержки — AI-чат на базе KB, с эскалацией на человека.

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

• Выбор платформы: Crisp / Intercom / Tawk.to
  • Crisp — дешевле, AI-addon, европейский
  • Intercom — дороже, больше фич, Fin AI
  • Tawk.to — бесплатно, но weaker AI
• Интеграция в admin (widget) + публичные страницы
• Обучение AI на KB (Фаза 2.3.2)
• Handoff к человеку: «talk to human» работает
• Ticket tracking: history, status, assignee
• Integration с Slack/email для escalation

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

• ❓ Crisp vs Intercom vs Tawk.to — cost/benefit analysis нужен
• Pricing: per seat, per conversation, flat?

Зависит от: — Блокирует: Фаза 2.3.3

2.3.2 — Knowledge Base (8 приоритетных статей)

Приоритет: Высокий · Отдел: Content + Product

Что это: База знаний для AI-чата + публичного self-service.

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

• 8 приоритетных статей (из launch-plan-v2):
  1. Быстрый старт: регистрация → первый проект за 15 минут
  2. Custom domain: как настроить DNS + troubleshooting
  3. Добавление проекта: Buildings → Levels → Units → Rooms
  4. Загрузка panorama и hotspots
  5. Управление floor plans и связь с юнитами
  6. Invite клиента (девелопера) с ограниченным доступом (✅ уже есть)
  7. Биллинг: plan change, invoice, cancel
  8. Features: что включает/выключает каждый toggle
• Формат: 300-500 слов + скриншоты + checklist в конце
• Embedded search
• «Was this helpful?» voting

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

• CMS для KB (Notion / Outline / GitBook / внутреннее)?
• Мультиязычность с запуска или только EN?

Зависит от: — Блокирует: Фаза 2.3.1 (AI учится на KB)

2.3.3 — Public FAQ + escalation

Приоритет: Средний · Отдел: Content + Ops

Что это: Публичный FAQ на landing-page + механизм перехода от AI к человеку.

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

• FAQ на landing с топ-10 вопросов pre-sales
• Escalation flow: AI не знает → «connect with support» → human reply
• Office hours указаны (transparency)
• SLA публично объявленный (24 часа для non-urgent в publiquement launch)
• Status page (uptime.com / statuspage.io) для incident communication

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

• Публичный status page с запуска или позже?

Зависит от: Фазы 2.3.1, 2.3.2 Блокирует: —

Было: 2.3.4 Feedback loop: ticket → KB article Перенесено в Раздел 6 (Процесс) — это не dev-задача, а operational process (weekly review, без эстимейта).

Фаза 2.4 — Инструменты сбора фидбека

Мы собираем количественный + качественный фидбек пока студии работают. Это входит в договорённость с пилот-программой.

2.4.1 — Heatmap + session recordings

Приоритет: Высокий · Отдел: Product + Tech · ⏱ · ❓

Что это: Инструмент который показывает где студии тыкают в пустоту, где останавливаются, откуда уходят.

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

• Выбор: Hotjar (платный, зрелый) vs MS Clarity (бесплатно, GDPR-compliant из коробки)
• Установка на admin + публичные страницы проектов
• Session recordings для топ-5 journeys (onboarding, project creation, unit setup)
• Cookie consent совместим (Фаза 1.6.4)
• Retention setting (GDPR-compliant)

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

• ❓ Hotjar vs Clarity — решение по бюджету и features

Зависит от: Фаза 1.6.4 (Cookie consent) Блокирует: —

2.4.2 — Product analytics (PostHog / Mixpanel)

Приоритет: Высокий · Отдел: Product + Tech · ⏱

Что это: События которые отслеживаем для понимания feature adoption и retention.

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

• Выбор: PostHog (self-hosted возможно) vs Mixpanel (managed)
• Ключевые события: signup, wizard steps, project created, building created, unit created, publish, share, payment
• User properties: plan tier, studio size, country
• Funnel analysis: signup → wizard complete → first project → publish
• Retention cohorts
• Feature adoption rates: кто использует Walkthroughs / Price List / Unit Statuses

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

• PostHog vs Mixpanel — какой покрывает нужды + бюджет?
• Self-hosted PostHog имеет смысл (контроль данных) или cloud быстрее?

Зависит от: — Блокирует: Фазу 2.4.4

2.4.3 — GA4 на публичных страницах

Приоритет: Средний · Отдел: Marketing + Tech

Что это: Традиционная web analytics на landing + публичных проектных страницах.

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

• GA4 install на landing + project pages
• Goals: trial signup, pricing view, demo request
• UTM tracking для marketing campaigns
• Search Console integration
• IP анонимизация (GDPR)

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

• GA4 vs Plausible/Simple Analytics (privacy-friendly альтернативы)?

Зависит от: Фаза 1.6.4 (Cookie consent) Блокирует: —

2.4.4 — Structured feedback form + weekly calls

Приоритет: Высокий · Отдел: Product + Ops · ⏱

Что это: Структурированная форма на каждый weekly call — чтобы фидбек был сопоставим между студиями.

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

• Weekly form: что сработало / что сломалось / что missing / priority 1/2/3 wishlist
• Форма в Typeform / Notion / custom — на выбор
• Weekly 30-min call с заполнением формы прямо на звонке
• Aggregation: все ответы в одном dashboard (Notion / Airtable)
• Monthly summary: топ-3 паттерна для команды

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

• Typeform / Notion / Airtable — что выбираем для агрегации?

Зависит от: Фаза 2.1.3 Блокирует: —

2.4.5 — Beta metrics dashboard

Приоритет: Высокий · Отдел: Product + Tech · ⏱

Что это: Один экран где видны ключевые метрики пилота.

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

• Metabase / Grafana / custom — tooling
• Метрики:
  • Активные студии (WAU, MAU)
  • Созданные проекты / неделя
  • Time to first project (среднее + distribution)
  • Support ticket load
  • Feature adoption %
  • Error rate
  • NPS (ежемесячный survey)
• Auto-refresh, доступ команде

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

• Tool: Metabase / Grafana / Notion view?

Зависит от: Фазы 2.4.1, 2.4.2 Блокирует: —

Фаза 2.5 — Итерации по фидбеку

Weekly sprint на основе фидбека. Мы не ждём конца пилота чтобы исправлять — делаем инкрементально.

2.5.1 — Weekly triage meeting

Приоритет: Высокий · Отдел: Product + Tech

Что это: Еженедельный 1-час meeting где команда смотрит фидбек, ранжирует и планирует спринт.

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

• Attendees: Project Lead, product team, tech team (lead), PM
• Input: feedback form aggregation (Фаза 2.4.4), chat logs, bug reports
• Triage: critical / high / medium / low / wontfix
• Output: список задач на next sprint
• Communication к студиям: что взяли, что не взяли и почему

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

• Fixed время (напр., пятница 16:00 GST) или плавающее?

Зависит от: Фаза 2.4.4 Блокирует: —

2.5.2 — Admin UX improvements по ходу

Приоритет: Высокий · Отдел: Design + Tech · ⏱

Что это: Улучшения admin которые не вошли в Стадию 1 (важные но не критичные) — делаем в ответ на фидбек пилота.

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

• Buildings pagination + sorting (Sергеевская заметка #1, #10)
• Enable/disable toggles (buildings, levels, units) (заметка #4)
• Click-to-preview (заметка #5)
• File conversion on upload (jpeg→webp) (заметка #12)
• Breadcrumbs everywhere
• Sticky forms (no progress loss)
• Labels & Terms UX cleanup

(См. Appendix D для полной карты заметок.)

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

• Какие из этих приоритетны по фидбеку пилотов?

Зависит от: Фаза 2.4 Блокирует: —

2.5.3 — Bug triage & fix cadence

Приоритет: Высокий · Отдел: Tech + QA

Что это: Процесс как баги от пилот-студий попадают в работу.

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

• Bug report template (replication steps, expected, actual, screenshots, env)
• Severity classification: P0 (data loss / security) / P1 (blocker) / P2 (degraded) / P3 (cosmetic)
• SLA по severity: P0 = 4 часа, P1 = 2 дня, P2 = sprint, P3 = backlog
• Tracker (Linear / Jira / GitHub Issues?)
• Regression tests для fix'нутых багов

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

• Какой tracker используется командой VV?

Зависит от: — Блокирует: —

Фаза 2.6 — Критерии выхода из пилота

Когда можем сказать «готовы к публичному запуску»? Чёткие метрики.

2.6.1 — Go/no-go критерии

Приоритет: Критично · Отдел: Product

Что это: Метрики которые говорят «да, идём в public launch» или «нет, продлеваем пилот».

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

• 80%+ пилот-студий активны (используют еженедельно)
• 70%+ создали 3+ проекта
• Critical + High баги = 0 open
• Average NPS >= 30
• AI-chat resolution >=60% без эскалации к человеку
• Error rate <1%
• Uptime >=99.5% за последний месяц

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

• Финальные threshold'ы — требуют согласования

Зависит от: Фаза 2.4.5 Блокирует: Стадию 3

2.6.2 — Post-pilot decision point

Приоритет: Критично · Отдел: Product + Sales

Что это: Формальная встреча (Project Lead + product team + tech team) где смотрим метрики, принимаем go/no-go.

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

• Presentation: pilot outcomes (метрики, кейсы, lessons learned)
• Decision: open doors сейчас / продлить пилот / добавить stage 2 пилота
• Communication к пилот-студиям о переходе (paid / continue free / migration)
• Press release / blog post (если go)
• Case studies opt-in from пилот-студий

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

• Что если go/no-go неоднозначен (часть метрик пройдена)?

Зависит от: Фаза 2.6.1 Блокирует: Стадию 3

2.6.3 — Pilot → Paid transition (механика перехода)

Приоритет: Критично · Отдел: Product + Ops + Legal · ⏱ · ❓

Что это: Когда пилот закончился и решение go — что конкретно происходит с 20 студиями? Механика перехода от free pilot к paid customer. Без продуманного процесса теряем пилот-студий в момент когда они должны стать первыми paying customers.

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

• Communication sequence (за 30 дней до окончания пилота):
  • Day -30: «Пилот заканчивается. Вот что дальше». Персонализированное письмо от Project Lead
  • Day -14: 1-on-1 звонок с каждой пилот-студией: пожелания, план перехода
  • Day -7: финальный reminder с выбором действия
  • Day 0: триггер действия
• Опции для пилот-студии:
  • A — Migrate to paid (с grandfathered discount 50% на первый год как благодарность)
  • B — Продлить пилот на 1-3 месяца (ограниченное количество кейсов)
  • C — Отменить подписку, данные сохраняются 90 дней в read-only
• Данные при отмене: по стандартной retention (Фаза 1.6.2) — 90 дней access → delete
• Reference / testimonial collection — прежде чем студия уйдёт (если C), запросить reference
• Case study / PR: публикация 3-5 success stories (см. Фаза 3.2.4)
• Automation: trigger emails / reminders через email-provider

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

• ❓ Grandfathered discount — 50% первый год / fixed price lock / что-то другое?
• ❓ Продление пилота — для всех кто просит или только для «активных advocate» студий?
• Automatic billing start или manual confirmation?
• Что если студия просит продления дольше 3 месяцев?

Зависит от: Фаза 2.6.1, 2.6.2 Блокирует: Стадию 3 (начало публичного запуска)

Стадия 3 — Публичный запуск

Цель стадии: Open doors. Любая студия в мире может зарегистрироваться и начать trial.

Условие выхода из стадии: первые 100 платящих студий, стабильные метрики, Stage 4 growth в работе.

Фаза 3.1 — Performance & Scale Testing

До публичного запуска нагрузочное тестирование должно подтвердить, что система держит обещанную нагрузку.

3.1.1 — Load test scenarios

Приоритет: Высокий · Отдел: Tech + QA · ⏱

Что это: Сценарии нагрузки которые должны пройти перед public launch.

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

• Targets: 100 concurrent studios админят, 200 concurrent посетителей на публичных страницах, 500 burst (выставка сценарий)
• Tool: k6 или Apache JMeter
• Scenarios: admin workflow, panorama loading, floor plan rendering, publishing, concurrent upload
• Automated run перед каждым релизом
• Baseline + регрессия: каждый релиз не ухудшает
• Reactive DB optimization: slow query log включён, топ-10 slow queries identified + проиндексированы если load test выявил проблемы (не proactive без замеров)

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

• Cloud для load-testing (AWS + k6 managed / self-hosted)?

Зависит от: — Блокирует: Стадия 3 launch

3.1.2 — 360° panorama performance

Приоритет: Высокий · Отдел: Tech · ⏱

Что это: Specific focus на critical path — panorama loading, так как это fancy-feature и плохая производительность бьёт по core value.

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

• Measure TTI (time to interactive) на 3G / 4G / WiFi
• Progressive loading (low-res сразу, high-res прогружается)
• Precaching для частых panoramas
• Fallback для слабых устройств / медленного интернета

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

• Есть ли benchmark какой TTI приемлем?

Зависит от: Фаза 3.1.3 Блокирует: —

3.1.3 — CDN для медиа

Приоритет: Высокий · Отдел: Tech + Ops · ⏱

Что это: Media (panoramas, floor plans, renders) — через CDN.

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

• Cloudflare / Bunny / CloudFront
• Origin: S3 (или equivalent)
• Cache rules: TTL, purge on update
• Signed URLs для private контента (студия A не видит студию B)
• Bandwidth cost modeling

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

• Какой CDN + pricing при нашей нагрузке?

Зависит от: — Блокирует: Фаза 3.1.2

3.1.4 — Image compression pipeline

Приоритет: Высокий · Отдел: Tech · ⏱

Что это: При upload — автоматическая конвертация jpeg/png → webp, optimized sizes per use case.

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

• Background worker (image conversion CPU-bound)
• WebP + fallback JPEG
• Multiple sizes (thumbnail, preview, full)
• Lazy loading с placeholder
• Покрывает Sергеевскую заметку #12

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

• Sharp / ImageMagick / cloud-based (Cloudinary)?

Зависит от: — Блокирует: Фаза 3.1.2

Было: 3.1.5 Database query optimization Объединено с Фазой 3.1.1 Load test scenarios — DB-оптимизация делается реактивно если load test выявляет slow queries, а не proactively. Premature optimization без замеров — антипаттерн.

3.1.6 — Lighthouse ≥80

Приоритет: Высокий · Отдел: Tech + Design · ⏱

Что это: Публичные страницы проектов — performance / accessibility / SEO / best practices score 80+.

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

• Lighthouse audit текущих страниц
• Исправления: lazy load, critical CSS, compressed fonts, async scripts
• Automated Lighthouse в CI (PRs не мержатся если score <80)
• Метрики: LCP, FID, CLS

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

• Какой baseline сейчас?

Зависит от: Фазы 3.1.3, 3.1.4 Блокирует: —

Фаза 3.2 — Marketing Launch

После пилота мы имеем testimonials, метрики, case studies — публичный маркетинг.

3.2.1 — PR & press outreach

Приоритет: Высокий · Отдел: Marketing

Что это: PR-активности вокруг public launch.

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

• Press release: «Первая PropTech-платформа с MCP для AI-агентов» (если MCP в скоупе Стадии 4)
• Outreach PropTech-медиа (TechCrunch, Inman, PropTech Connect)
• Pitch blogger'ам в real estate и rendering niches
• Podcast appearances

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

• Есть ли PR-подрядчик или внутренний маркетинг?

Зависит от: — Блокирует: —

3.2.2 — Content marketing

Приоритет: Высокий · Отдел: Marketing + Content

Что это: SEO-driven контент на blog для органического трафика.

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

• Blog на landing (WordPress / Ghost / internal)
• 10 статей в первые 3 месяца:
  • «How to sell off-plan property: playbook»
  • «360° walkthroughs vs photos: conversion data»
  • «GDPR для real estate companies»
  • «Kuula vs Matterport vs Volume Vision»
  • etc.
• Guest posts на PropTech публикациях

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

• Кто пишет (внутренняя команда / freelancers)?

Зависит от: — Блокирует: —

3.2.3 — Paid ads (Google / LinkedIn)

Приоритет: Средний · Отдел: Marketing

Что это: Платный трафик на landing для ускоренного набора первых paying customers после пилота.

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

• Google Ads: keyword research для PropTech / off-plan / rendering studio
• LinkedIn Ads: B2B decision-makers (real estate agencies, rendering studios)
• Ad creative + landing variations для A/B
• Budget: $2-5k/месяц на старте
• Measurement: CAC (customer acquisition cost), LTV:CAC ratio

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

• Бюджет на первые 3 месяца после public launch?

Зависит от: Фазы 3.1, 3.2.1 Блокирует: —

3.2.4 — Case studies from pilot

Приоритет: Высокий · Отдел: Marketing + Sales

Что это: Публикация 3-5 case studies от пилот-студий с конкретными цифрами.

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

• Отбор 3-5 пилот-студий с лучшими результатами
• Interview + data collection
• Written case study (500-1000 слов)
• Short video (3-5 минут)
• Publishing на landing + LinkedIn

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

• Как компенсировать студию за участие (скидка / cash / ничего)?

Зависит от: Стадия 2 complete Блокирует: Фаза 3.2.3

3.2.5 — Referral program (with credits system)

Приоритет: Средний · Отдел: Marketing + Product + Tech · ⏱

Что это: Существующие клиенты приводят новых за вознаграждение. Объединяет то что раньше было разложено на две фазы (3.2.5 + 4.2.6) — referral mechanism и credits system как одно целое.

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

• Referral attribution:
  • Unique referral code на каждый account
  • Invite flow: email / shareable link / QR
  • Cookie-based attribution (30-90 дней)
  • UI в админке «Invite a studio, get rewards»
• Reward structure (two-sided):
  • Приглашающий получает credit (1 месяц free subscription)
  • Приглашённый получает скидку 20% на первый месяц (incentive to signup)
• Credits system:
  • Credit balance per tenant (видимый в billing UI)
  • Auto-applied to next invoice
  • Expiry policy (6-12 месяцев)
  • Credits transferable между tenant'ами studia — no (security concerns)
• Tracking:
  • Dashboard: кто привёл скольких, conversion rate, revenue attribution
  • Leaderboard (optional) — топ referrer'ы публично
• Anti-abuse:
  • Rate limit invite'ов per account
  • Prevent self-referral (same payment method)
  • Review перед credit applied (первые 50 случаев manual)

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

• Two-sided (обе стороны получают) или one-sided (только приглашающий)?
• Reward: 1 месяц free / % скидка / $ credit — что проще и лучше конвертирует?
• Cap на количество rewards — unlimited или лимит 10/year?

Зависит от: Фаза 1.5.4 (billing UI) Блокирует: —

Фаза 3.3 — Admin UX v2 Improvements

Улучшения, приоритизированные по фидбеку пилота. Некоторые уже начаты в Фазе 2.5.2 — здесь финализация.

3.3.1 — Finalised UX improvements from pilot

Приоритет: Высокий · Отдел: Design + Tech · ⏱

Что это: Топ-10 улучшений по priority из pilot feedback.

Что конкретно нужно сделать: (Это рандомный список — реальный приоритет по фидбеку)

• Bulk operations (mass enable/disable, mass status change)
• Keyboard shortcuts для power users
• Dark mode (если просят много студий)
• Improved search / filters
• Better error messages everywhere
• Help tooltips
• Export data (CSV для units / floor plans)

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

• Что будет реально в топ-10 по фидбеку?

Зависит от: Стадия 2 Блокирует: —

3.3.2 — Notifications (in-app + email)

Приоритет: Средний · Отдел: Tech · ⏱

Что это: Уведомления о событиях — клиент просмотрел, новый лид, изменения.

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

• In-app notification bell (pro-level studios просят)
• Email digest (daily / weekly / instant)
• Event types: lead submitted, client viewed project, payment received, plan expiring
• Preferences (отключить некоторые типы)
• Covers Сергеевскую заметку о уведомлениях

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

• Push notifications (web / mobile) — scope?

Зависит от: — Блокирует: —

3.3.3 — Audit log (who changed what)

Приоритет: Высокий · Отдел: Tech · ⏱

Что это: Логирование действий для studio-devs accountability + compliance.

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

• Log: user, action, entity, timestamp, old value, new value
• UI: history tab на каждом entity (building, unit, etc.)
• Admin-wide log для VV team
• Retention: 12 месяцев
• Export (CSV)

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

• Какие actions логируем (всё или важные)?

Зависит от: — Блокирует: —

Фаза 3.4 — Mobile Admin

Менеджер студии часто работает «не за компьютером» (on-site у клиента, в дороге).

3.4.1 — Responsive admin layout

Приоритет: Средний · Отдел: Design + Tech · ⏱

Что это: Текущая админка, адаптированная для mobile/tablet.

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

• Responsive breakpoints для всех ключевых страниц
• Touch-friendly controls (larger hit targets)
• Collapsible sidebar
• Simplified forms (meno полей одновременно)
• Performance: mobile network realities

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

• Scope: все страницы admin или только критичные (просмотр + редактирование цен)?

Зависит от: — Блокирует: Фазу 3.4.2

3.4.2 — Mobile-specific workflows

Приоритет: Средний · Отдел: Design + Tech · ⏱

Что это: Flows которые делаются с мобилы чаще (quick price update, status change).

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

• «Quick actions» menu
• Price update одной кнопкой (без захода в форму)
• Status toggle (available/reserved/sold) прямо из списка
• Quick notifications view

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

• Native app (iOS/Android) или PWA — в scope публичного запуска или Фазы 4?

Зависит от: Фаза 3.4.1 Блокирует: —

3.4.3 — Mobile upload flow

Приоритет: Средний · Отдел: Tech + Design · ⏱

Что это: Фото с телефона → сразу в админку.

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

• Camera access (HTML5 / getUserMedia)
• Upload с прогрессом (большие файлы на mobile network)
• Crop / edit перед upload
• Resume upload если прервалось

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

• Упрощённый upload или полноценный?

Зависит от: Фаза 3.4.1 Блокирует: —

Фаза 3.5 — SLO + Runbooks

Перед public launch мы формализуем что обещаем и что делать когда ломается.

3.5.1 — SLO / SLI definitions

Приоритет: Высокий · Отдел: Tech + Ops · ⏱

Что это: Формальные Service Level Indicators и Objectives.

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

• SLI: uptime %, p50/p95/p99 latency, error rate
• SLO: 99.5% uptime (из ToS), p95 <500ms для admin, <2s для публичных
• Alerting на SLO burn rate
• SLA (внешний) = SLO - safety margin

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

• Какие error budgets tolerable?

Зависит от: Фаза 1.7.3 (error tracking + alerting) Блокирует: —

3.5.2 — Runbooks для топ-инцидентов

Приоритет: Высокий · Отдел: Tech + Ops · ⏱

Что это: Документированные процедуры для частых инцидентов.

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

• Topics: database down, CDN issue, payment provider outage, mass signup failure, DDoS
• Шаблон runbook: symptoms, diagnostic steps, mitigation, escalation
• Living document (обновляется после каждого инцидента)

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

• Хранение (Notion / internal wiki)?

Зависит от: — Блокирует: —

3.5.3 — Status page (public)

Приоритет: Средний · Отдел: Ops · ⏱

Что это: Публичная страница с uptime и инцидентами. Используем готовое решение (statuspage.io / instatus / Better Stack) — custom не строим.

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

• Выбор провайдера (statuspage.io / instatus / Better Stack) — tech-team решение
• Integration с нашими health-check endpoints для auto-update
• Manual incident posts template
• Subscribe: студии получают email при инциденте
• Redirect status.offplan.online → status page

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

• —

Зависит от: — Блокирует: —

3.5.4 — Secrets management + key rotation

Приоритет: Критично · Отдел: Tech · ⏱

Что это: Переезд с хранения secrets в .env + CI env vars на production-grade secrets manager. Делаем ДО публичного запуска, но НЕ до пилота (для 20 пилот-студий текущего подхода достаточно).

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

• Audit где живут secrets (репо / .env / CI / runtime)
• Переход на secrets manager (Vault / AWS Secrets Manager / Doppler)
• Политика rotation: какие ключи ротируются как часто
• Разделение prod/staging/dev secrets (не должно быть overlap)
• Audit access: кто имеет доступ к prod secrets
• Автоматизация rotation для критичных ключей (JWT, DB)

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

• Какой secrets manager (Vault self-hosted / managed)?
• Compliance requirement по частоте rotation (SOC2 готовность)?

Зависит от: — Блокирует: Публичный запуск (перед Стадией 3 exit)

Стадия 4 — Рост и масштабирование

Цель стадии: Продукт масштабируется по features, CRM-интеграциям и монетизации. Начинаем Admin redesign (3 views).

Условие выхода из стадии: (это не stage с exit — это ongoing growth phase)

Фаза 4.1 — API / Webhooks / MCP

Основной запрос от агентств — интеграция с их CRM.

4.1.1 — Webhooks для ключевых событий

Приоритет: Высокий · Отдел: Tech · ⏱

Что это: Студии получают уведомления о событиях в их CRM через webhooks.

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

• Events: register_interest (лид), unit.status_changed, unit.price_changed, project.created
• Configuration UI: студия добавляет webhook URL + secret
• Retry logic: exponential backoff, 3 attempts, DLQ
• Delivery logs (студия видит что когда было отправлено)
• Signature verification (HMAC)

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

• Какие события самые запрошенные (по фидбеку пилота)?

Зависит от: — Блокирует: —

4.1.2 — API v1 documentation (Swagger/OpenAPI)

Приоритет: Высокий · Отдел: Tech · ⏱

Что это: Публичная API документация для интеграторов.

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

• Audit existing API endpoints
• OpenAPI 3.0 spec
• Interactive docs (Swagger UI / Redoc)
• Versioning (v1, v2 backwards compat)
• Authentication guide
• Rate limits doc
• Changelog

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

• Hosted docs (Stoplight / Readme) или self-hosted Swagger UI?

Зависит от: — Блокирует: Фаза 4.1.4

4.1.3 — Sandbox environment

Приоритет: Высокий · Отдел: Tech · ⏱

Что это: Test environment для интеграторов / разработчиков — без влияния на prod.

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

• Отдельный sandbox domain (sandbox.offplan.online)
• Test-mode API keys
• Seeded sample data (fake studios / projects)
• Reset on demand
• Документация как пользоваться

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

• Автоматические reset каждую ночь или по запросу?

Зависит от: — Блокирует: Фаза 4.1.4

4.1.4 — CRM integration examples

Приоритет: Средний · Отдел: Tech + Marketing · ❓

Что это: Готовые примеры интеграции с топ-3 CRM (HubSpot / Salesforce / Pipedrive).

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

• Выбор топ-3 по запросу пилот-студий
• Для каждого: GitHub repo с примером кода
• Blog post с пошаговой инструкцией
• Zapier / Make integration (для non-tech студий)

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

• ❓ Какие CRM приоритетны (HubSpot / Salesforce / Pipedrive / другие)?

Зависит от: Фазы 4.1.1, 4.1.2 Блокирует: —

4.1.5 — MCP server wrapper

🔴 Перенесено в Стадию 1 — Фаза 1.3 (ревизия 2026-04-27). Сергей: «Без MCP не запускаться.» Подробное описание, обоснование и подзадачи — см. Фазу 1.3.

Фаза 4.2 — Продвинутая монетизация

Оптимизация revenue после того как базовая подписка уже работает.

4.2.1 — Full 3-tier launch

Приоритет: Средний · Отдел: Product + Tech

Что это: Полноценный запуск 3 планов (Starter / Studio / Agency) с правильными limits и features.

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

• Lock features per план (feature flags per tier)
• Over-limit warnings (approaching / exceeded)
• Auto-upgrade promptы
• A/B test pricing

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

• Финальные лимиты (проекты / рендеры / users per план)

Зависит от: Фаза 1.4 Блокирует: Фаза 4.2.2

4.2.2 — Metered billing для рендеров

Приоритет: Средний · Отдел: Tech + Finance · ⏱

Что это: Если студия превысила quota рендеров — pay-per-use.

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

• Track renders per tenant
• Overage price per unit
• Alerts approaching quota
• Invoice lines per overage period
• Stripe / Paddle metered billing API

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

• Pricing модель: per render vs bundle?

Зависит от: Фаза 4.2.1 Блокирует: —

4.2.3 — Annual billing + discount

Приоритет: Средний · Отдел: Tech

Что это: Годовая оплата с скидкой 20% (стимулирует upfront payment + retention).

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

• UI выбора billing period
• Proration при переходе monthly→annual или обратно
• Renewal automation
• Communication (30 дней до renewal)

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

• % скидки?

Зависит от: Фаза 4.2.1 Блокирует: —

4.2.4 — Dunning (failed payment handling)

Приоритет: Высокий · Отдел: Tech + Ops · ⏱

Что это: Что происходит если карта expired или списание failed.

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

• 3 retry attempts за 7 дней
• Email sequence: Day 1 (failed), Day 3 (retry), Day 7 (final warning), Day 8 (downgrade)
• Grace period access (read-only)
• «Update card» flow в admin
• Recovery playbook

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

• Policy после 8 дней: downgrade / full block / данные через 90 дней?

Зависит от: Фазы 1.5.3, 1.5.6 Блокирует: —

4.2.5 — Enterprise plan (custom quotes)

Приоритет: Низкий · Отдел: Product + Sales

Что это: Для крупных агентств — custom pricing, SLA, dedicated support.

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

• «Contact sales» CTA на pricing page
• Quote workflow (CRM в Notion / HubSpot)
• Contract template (legal review per deal)
• Account manager assignment

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

• Сам ли Project Lead закрывает или нужен Sales rep?

Зависит от: — Блокирует: —

Было: 4.2.6 Referral credits Объединено с Фазой 3.2.5 — referral program теперь включает credits system как одно целое.

Фаза 4.3 — Admin Redesign: 3 Views

Подход Ильи: не переделываем всё с нуля — добавляем 2 новых view рядом с classic. Детали в Appendix A + визуальный mockup в docs/launch-plan-v3-visual.html.

4.3.1 — Classic view continuous improvement

Приоритет: Средний · Отдел: Design + Tech · ⏱

Что это: Текущий admin продолжает улучшаться инкрементально.

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

• Fold в текущие улучшения из пилот-фидбека
• Palette refresh: sand/gold вместо «cheap» светофоров (из Сергеевского фидбека)
• Typography refresh
• Spacing / whitespace consistency
• Component library consolidation

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

• Дизайнер для refresh (внутренний / подрядчик)?

Зависит от: — Блокирует: —

4.3.2 — Power Editor (Excel-like mass editing)

Приоритет: Средний · Отдел: Design + Tech · ⏱

Что это: Идея Ильи: когда много изменений — открываешь Power Editor, видишь все units в grid'е как в Excel, редактируешь inline.

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

• Spreadsheet-like grid (react-data-grid / ag-grid / handsontable)
• Inline editing с валидацией
• Copy-paste (из Excel)
• Bulk actions (select all / mass update / mass delete)
• Import CSV
• Export CSV
• AI-prompt integration (будущая Фаза 4.3.4)
• Use cases: initial bulk setup, quarterly price updates, status sync

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

• Grid library выбор — free vs paid features?
• CSV format specification?

Зависит от: — Блокирует: Фаза 4.3.4

4.3.3 — Visual Editor (inline на фронте)

Приоритет: Низкий-Средний · Отдел: Design + Tech · ⏱

Что это: Запрос product team (после демо похожего продукта) — пользователь заходит на live-страницу проекта, включает Edit Mode, меняет заголовки / описания / цены прямо на фронте. Подход tech team: этот view — дополнение к classic, не замена.

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

• «Edit Mode» toggle (только для аутентифицированных с правом)
• Contenteditable + validation для editable полей
• Save перед переключением секции
• Audit log integration
• Scope limit: не все editable (not floor plan geometry, only labels/prices)

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

• Что именно editable в visual mode (scope)?
• Conflict resolution если несколько пользователей editing одновременно?

Зависит от: — Блокирует: —

4.3.4 — AI editing mode

Приоритет: Низкий · Отдел: Tech + Product · ⏱

Что это: AI-агент в Power Editor: «обнови цены всех 2BR юнитов на +5%».

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

• LLM integration (Anthropic / OpenAI)
• Context: полная structure текущего tenant
• Confirmation preview перед apply
• Audit log всех AI-actions
• Safety: read → suggest → user confirms → apply

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

• Bundled с MCP server или отдельно?

Зависит от: Фазы 4.3.2, 4.1.5 Блокирует: —

4.3.5 — Full design system (расширение 1.1.3)

Приоритет: Низкий · Отдел: Design · ⏱

Что это: На Стадии 1 (Фаза 1.1.3) мы делаем минимальный refresh палитры для пилота (убрать traffic-lights, базовая sand/gold палитра). Эта фаза — полный формализованный design system: Figma library, token'ы для всех компонентов, documentation, component library как code package для всех admin views (Classic + Power + Visual).

Разница с 1.1.3:

• 1.1.3 = минимум для пилота: status indicators + accent colors + typography audit (~1-2 недели)
• 4.3.5 = полная design system: reusable component library, Figma, docs, guidelines (~4-6 недель)

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

• Figma library со всеми компонентами (buttons, inputs, tables, cards, callouts, modals, forms)
• Design tokens в коде (CSS variables / Tailwind / Linaria)
• Documentation (Storybook или аналог) — living reference для dev
• Migration всех existing UI на новый system
• Accessibility check (contrast, focus states) — связано с Q36
• Dark mode support (optional, if requested)

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

• Storybook vs alternative (Ladle, Histoire)?
• Tailwind utility-first или CSS modules?
• Dark mode — обязательно или opt-in per user?

Зависит от: Фаза 1.1.3 (pre-pilot refresh) Блокирует: —

4.3.6 — Customization (font + button roundness)

Приоритет: Низкий · Отдел: Design + Tech · ⏱

Что это: Студия кастомизирует свои публичные страницы: шрифт, скругление кнопок, layout variants.

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

• Theme variables в admin (font family, button radius 0-20, primary color, secondary)
• Preview в admin
• Применяется на публичных страницах (не admin)
• Defaults на основе сильных sensible defaults

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

• Custom CSS для enterprise?

Зависит от: — Блокирует: —

Фаза 4.4 — Локализация

4.4.1 — i18n infrastructure

Приоритет: Средний · Отдел: Tech · ⏱

Что это: Ready для добавления языков.

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

• i18n library (react-i18next / formatjs)
• Extraction pipeline (все strings → translation keys)
• Pluralization / formatting rules
• Date/number locale
• RTL ready для будущего арабского

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

• Библиотека: react-i18next vs formatjs?

Зависит от: — Блокирует: Фазу 4.4.3

4.4.2 — Translation pipeline

Приоритет: Средний · Отдел: Product + Tech

Что это: Как переводы появляются + обновляются.

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

• Source of truth: JSON / YAML в репо
• Translation service: Lokalise / POEditor / Crowdin / manual
• Reviewer workflow (native speaker approve)
• Continuous updates (new strings)

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

• Managed vs manual (если только 2-3 языка)?

Зависит от: Фаза 4.4.1 Блокирует: Фазу 4.4.3

4.4.3 — EN baseline

Приоритет: Средний · Отдел: Content

Что это: Полный английский перевод (source language).

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

• Audit всех hardcoded strings
• Extraction в translation keys
• Review quality + consistency
• Style guide (tone, terminology)

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

• —

Зависит от: Фазы 4.4.1, 4.4.2 Блокирует: Фазу 4.4.4

4.4.4 — Second language decision

Приоритет: Средний · Отдел: Product + Marketing · ❓

Что это: Какой второй язык добавить после EN.

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

• Data-driven decision: по signup geography + target markets
• Candidates: Arabic (UAE/GCC), German (DACH), French, Spanish, Russian
• Translation + review + launch
• Market-specific adjustments (RTL для арабского)

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

• ❓ Требует решения Ромы и маркетинга

Зависит от: Фаза 4.4.3 Блокирует: Фазу 4.4.5

4.4.5 — RTL support (если арабский)

Приоритет: Низкий · Отдел: Tech · ⏱

Что это: Bidi / RTL layout если выбран арабский.

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

• CSS logical properties (margin-inline-start etc.)
• Layout testing с RTL
• Icons mirroring
• Form inputs behaviour

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

• —

Зависит от: Фаза 4.4.4 Блокирует: —

Фаза 4.5 — Advanced Features

Features которые не обязательны для launch но сильные differentiators.

4.5.1 — Compare units (buyer-facing)

Приоритет: Низкий-Средний · Отдел: Tech + Design · ⏱

Что это: Покупатель выбирает 2-3 юнита → таблица сравнения.

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

• Multi-select из списка units
• Сравнительная таблица: area, price, floor, view, status
• Shareable link (для клиентов которые не хотят регистрироваться)
• Mobile-friendly

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

• Scope: только same project или cross-project?

Зависит от: — Блокирует: —

4.5.2 — Remote co-browse (WebRTC)

Приоритет: Низкий · Отдел: Tech · ⏱

Что это: Агент ведёт покупателя удалённо по 3D-туру (shared cursor, voice).

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

• WebRTC / cursor sharing / voice chat
• Session management (пригласительная ссылка)
• Recording (optional)

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

• Build vs integrate (Calendly + Zoom flow)?

Зависит от: — Блокирует: —

4.5.3 — PDF import for floor plans + AI conversion

Приоритет: Низкий-Средний · Отдел: Tech + Product · ⏱

Что это: Сергеевская заметка #6 — PDF не принимается сейчас, но часто застройщики присылают именно PDF.

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

• PDF upload endpoint
• AI conversion pipeline (GPT-4V / Claude / specialized): vectorize + crop + background removal
• Human review step (optional для начала)
• Output: PNG/WebP с правильными параметрами

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

• Автоматическая конвертация или manual review каждой?
• Какой AI-provider для vision tasks?

Зависит от: — Блокирует: —

4.5.4 — AI-assisted content generation

Приоритет: Низкий · Отдел: Tech + Product · ⏱

Что это: AI помогает писать описания юнитов, amenities, projects.

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

• Prompts для разных entities
• Edit-review-approve UX
• Token consumption tracking (кто платит — студия или VV)
• Style adherence (studio tone of voice)

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

• AI как бесплатная фича или per-token usage billing?

Зависит от: — Блокирует: —

Параллельно в работе у tech team

Два трека, которые tech team ведёт независимо от этого плана. Упоминаются здесь для синхронизации scope'а и избежания дублирования усилий.

P.1 — Hotspot UX overhaul ✅

Редизайн хотспотов на фасаде здания (см. Фаза 4.5.5 выше). В активной разработке у tech team.

P.2 — Новая админка с AI-assistance ✅

Tech team ведёт отдельный трек по построению следующей версии admin с AI-assisted workflows. Когда этот трек дойдёт до релиза — 3-view концепция (Classic + Power Editor + Visual Editor) из Фазы 4.3 естественно ляжет в новый фундамент. План offplan.online синхронизируется со scope'ом и приоритетами этого трека на еженедельных встречах.

Практическое следствие: задачи из Фазы 4.3 не начинаются в старой админке, а интегрируются в новую по мере её готовности. Это влияет на порядок работ — продолжать обсуждать с tech team.

5. Команда и пропускная способность

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

Новая роль в этом плане:

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

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

Вопрос к команде Ильи: реальный эстимейт по Фазам Стадии 1 в разбивке по ролям. После этого ясно можно ли распределить нагрузку или нужно усиление (дополнительный frontend / backend / дизайнер / юрист).

6. Процесс эстимирования и взаимодействия

6.1 — Cadence Project Lead ↔ Tech Lead

• 2-3 звонка в неделю (согласовано на звонке 2026-04-24)
• Формат: 30-60 минут, повестка заранее

6.2 — Эстимирование

Предложенный процесс:

1. Project Lead + AI-ассистент готовят task-level описание из плана
2. Передают Илье на eстимейт
3. Tech team (lead) разбивает по ролям (frontend / backend / design / QA) и возвращает дни
4. Созваниваются, обсуждают что можно ускорить / распараллелить
5. Результат → в план (замена ⏱ на конкретные дни)

6.3 — Backlog VV

Запрошенный доступ к VV backlog — чтобы понять что уже делается параллельно. ⏱ ожидается от Ильи.

6.4 — Прод-подобное окружение для Сергея

Запрошено «teremki.offplan.online» (или подобное) — prod-like environment где Project Lead может тестировать как клиент. ⏱ ожидается от tech team.

6.5 — Feedback loop: ticket → KB article

Если студия спрашивает — значит KB недостаточна. Каждый unanswered вопрос превращается в статью. Это operational process, не dev-задача — начинаем с первой недели пилота и продолжаем continuous.

Как работает:

• Weekly review (30 минут, Ops + Content lead): просмотр топ-5 вопросов в chat за неделю
• Missing answer → article: если AI-чат не смог ответить и операторы отвечали manually → создаём KB-статью по шаблону
• Auto-suggestions from AI: chat-platform (Crisp/Intercom) предлагает «вы уже отвечаете на этот вопрос 5 раз, создать статью?»
• Метрика для отслеживания: % AI-answered без эскалации к человеку (целевая ≥60% на выходе из пилота, ≥80% через 3 месяца публичного запуска)

Кто ведёт: CS/Ops lead (после пилота — возможно dedicated CS hire).

Связано с: Фаза 2.3 (Support Infrastructure) — после развёртывания AI-чата и KB этот процесс запускается сразу.

Appendix A — Admin Panel Concept (3 Views)

Полный визуальный референс с v4 mockup: docs/launch-plan-v3-visual.html.

Кратко концепция (для обсуждения с product team и tech team):

Проблема: Текущий admin работает, но UX — «alpha-версия» (по собственной оценке команды). Переделывать всё с нуля — слишком дорого и рискованно. Подход Ильи: не переделываем, добавляем views.

Три view параллельно:

1. Classic view (текущий admin) — для детального редактирования отдельных entities. Продолжает улучшаться инкрементально.
2. Power Editor (новый) — Excel-like grid для массового редактирования. Use cases: initial bulk setup, quarterly price updates, status sync. Также — платформа для AI-режима редактирования (лучше работает когда видно всё сразу).
3. Visual Editor (новый) — inline на публичной странице. Light-touch редактирование (labels, prices, descriptions) — запрос product team после демо похожего продукта. Не замена classic, а дополнение для quick edits.

Визуал: sand/gold/navy палитра (как в v4 mockup) — замена «cheap» традиционного UI. Встроенный numbered wizard 1→10 в sidebar для онбординга.

Файл визуального референса: docs/launch-plan-v3-visual.html.

Appendix B — 20 новых вопросов

Дополняют 44 вопроса из launch-plan-v2 (Appendix C). Акцент на security, rate limiting, reliability.

Security (7)

Rate Limiting / DoS (3)

Reliability / Backup (3)

Scaling / Performance (2)

Monitoring / SLO (2)

Auth / SSO (2)

Compliance (1)

Appendix C — 44 существующих вопроса (из launch-plan-v2)

См. полный список в plans/launch-plan-v2.md (Блок 1, секции 1.1 и 1.2). Все остаются актуальными. Ключевые, требующие обновления ответов:

• Вопрос 4 (Invite клиента): ✅ закрыт — функция уже есть в админке
• Вопрос 11 (tenant isolation): раскрыт детально в N1-N2 Appendix B
• Вопросы 20 (ошибки), 21 (бэкапы): раскрыты в N11-N17 Appendix B
• Вопрос 12 (SSO): раскрыт в N18 Appendix B

Appendix D — 17 заметок из тестирования (Project Lead, 2026-04-24)

Итого: 6 заметок 🔬 требуют проверки на продакшене прежде чем быть включёнными в sprint.

Appendix E — Открытые вопросы (сквозная таблица)

Вопросы, требующие решения прежде чем соответствующие задачи могут пойти в работу. Каждый помечен: чей ход + что нужно для закрытия.

Итого: 38 открытых вопросов.

• 8 из них — критичные (блокируют Стадию 1): Q1, Q2, Q3, Q6, Q10, Q11, Q13, Q37
• 4 — стратегические (требуют обсуждения прежде чем определять детальные задачи): Q31, Q32, Q34, Q38
• 3 помечены 🔧 — tech-decisions, не требуют обсуждения менеджмента, решает tech team самостоятельно: Q18, Q22, Q26

Расширенные стратегические вопросы (Q31–Q38)

Для следующих вопросов таблица выше недостаточна — они требуют обсуждения с развёрнутым контекстом. Каждый блок — что за вопрос, почему важен, что нужно решить, кто закрывает.

Q31 — Data export + Right to erasure (GDPR Art. 17 + 20)

Закрывает: Product team + Legal + Tech team · Связано с: Фаза 1.5 (Legal), возможно новая задача в Стадии 2

В чём суть: Две парные GDPR-обязанности:

• Art. 20 (Data Portability) — студия может выгрузить все свои данные в машиночитаемом формате
• Art. 17 (Right to Erasure / Right to be Forgotten) — студия может запросить полное удаление своих данных

Без обоих — нарушение GDPR + отсутствие business trust.

Почему важно:

• Legal: GDPR штрафы до 4% annual revenue за нарушение
• Business trust: #1 sales objection в B2B SaaS: «что если я уйду? смогу забрать данные и закрыть аккаунт?» Без этого студия не подпишется
• Practical: миграция на другой tool, regular backup, compliance audit

Что входит в export (Art. 20):

• Структура проектов (JSON) — buildings, levels, units, floor plans
• Медиа (ZIP с оригиналами) — panoramas, renders, floor plans
• Users / permissions
• Лиды (CSV) — все Register Interest
• Билинг-история + invoices (PDF)
• Audit log

Что входит в erasure (Art. 17):

• Удаление всех personal data пользователя / tenant'а
• Retention log — запись самого факта удаления (для audit, anonymous)
• Каскадное удаление в backups (или документированная процедура как они expires)
• Exclusion: legal hold data (налоговые инвойсы — хранятся 7 лет независимо от erasure)

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

1. Basic (до пилота): кнопка «Export» + кнопка «Delete account» → async + email confirm (~1-2 недели dev)
2. Full (до публичного launch): все данные, multiple formats, API endpoint, scheduled exports (~2-3 недели dev)
3. Real-time (enterprise): webhook-driven sync в S3-бакет клиента

Что решить:

• Scope: project-level / tenant-level / всё
• Форматы export: наш JSON + стандартные (glTF / CSV / PDF)
• Когда: до пилота (GDPR-compliance с первого дня) или до публичного launch?
• Erasure — self-serve (кнопка) или только manual request (ticket)?
• Retention после erasure — какие данные остаются (legal hold)?
• Freemium — basic для всех / advanced для enterprise?

Q32 — Migration существующих VV-клиентов

Закрывает: Product team + Legal · Связано с: стратегический вопрос, влияет на всю Стадию 1

В чём суть: У VV есть текущая клиентская база — они на bespoke-контрактах (не self-serve SaaS). Как эти клиенты взаимодействуют с новой SaaS-платформой?

Варианты:

1. Mandatory migration — все существующие клиенты мигрируют на SaaS, bespoke контракты прекращаются. Чистый, но болезненный
2. Optional migration — клиент сам решает. Потенциал duality (обе модели живут параллельно)
3. No migration — SaaS только для новых клиентов, существующие остаются как есть. Нет потрясений, но бренд разделяется
4. Hybrid — SaaS для новых, существующие мигрируют только если захотят (с compensation)

Что решить:

• Какой из 4 вариантов?
• Compensation для мигрирующих (скидка / credits / grandfathered price / enterprise SLA)?
• Timeline миграции (6 мес / 12 мес / indefinite)?
• Отдельные SLA и feature-set для legacy vs SaaS клиентов?
• Кто ведёт процесс (отдельный CS-менеджер)?

Риски если не решить:

• Существующие клиенты узнают о SaaS случайно → недовольство
• Dual-model создаёт комплексность для tech team (две кодовые базы, две структуры биллинга)
• Возможно legal-обязательства перед существующими клиентами (notice period, price lock)

Q33 — Content moderation + DMCA

Закрывает: Legal + Product team · Связано с: Фаза 1.5 (Legal) + новая задача

В чём суть: Защита от трёх рисков — copyright infringement (студия загружает чужие рендеры), AUP violations (неуместный / фейковый / malware контент), geographic restrictions (KSA требует content filtering).

DMCA specific:

• DMCA Designated Agent — регистрация в US Copyright Office ($6 fee) обязательна для Safe Harbor protection
• Takedown process — [email protected] + шаблон notice, 24-48h SLA
• Counter-notice — студия может оспорить (10-14 days safe harbor period)
• Repeat infringer policy — 3 обоснованных жалобы = terminate

AUP specific:

• Чёткий AUP в ToS (Фаза 1.5.1)
• Report button на публичных страницах
• Manual review queue для reports
• Suspension flow (temporary / permanent)

Что решить:

• DMCA agent регистрируем до пилота (safe) или до public launch (cheap)?
• Moderation: manual review queue (дешёво, медленно) или automated scanning (дорого, быстро)?
• NSFW / content filtering обязателен в Стадии 1 или откладываем?
• Content hash scanning (PhotoDNA) — overkill для нас, но рассмотреть для enterprise

Timing:

• Pilot: низкий риск (20 curated studios)
• Public launch: высокий риск (любой может зарегаться) → нужно реализовать до Стадии 3

Q34 — Geographic data sovereignty

Закрывает: Tech team + Product team + Legal · Связано с: Фаза 1.1 (Infrastructure) + long-term architecture

В чём суть: Некоторые юрисдикции требуют физическое хранение данных локально. НЕ путать с GDPR (который разрешает export данных с SCCs — Standard Contractual Clauses).

Кто требует:

• EU GDPR — не требует «данные в EU», но strict control на transfer в third countries. UAE = third country без adequacy
• UAE DPR — отдельные сектора требуют local storage (real estate пока нет, но может поменяться)
• KSA PDPL — с 2024 требует local hosting для sensitive data
• China / Russia — не наши рынки, но примеры жёсткой localization

Архитектурные варианты:

1. Single region (дёшево, просто) — одна default region (EU-West). Отказываемся от клиентов с local-требованиями
2. Multi-region read replicas (средне) — source of truth EU, read-replicas в UAE для latency
3. Per-tenant region (дорого, сложно) — tenant выбирает регион при signup, данные разделены
4. Per-tenant instance (очень дорого) — отдельный cluster в выбранном регионе (enterprise-only)

Что решить:

• Default region на старте (EU-West / US / UAE)?
• Multi-region roadmap — когда (6 мес / 12 мес / никогда)?
• Какие enterprise-требования мы готовы принимать (если да — на каком ценовом уровне)?
• Data residency как feature в контрактах — только enterprise или всем?

Риск:

• Single region + EU-клиент с local-требованием = теряем сделку
• UAE-клиент с требованием AWS Bahrain / Azure UAE — потеря GCC-сегмента без multi-region

Q35 — Channel strategy: direct / partners / marketplace

Закрывает: Product team + Marketing + Sales · Связано с: Фаза 3.2 (Marketing Launch)

В чём суть: Как продаём продукт — определяет go-to-market и влияет на structure маркетинг-команды, pricing, tooling.

Возможные channels:

1. Direct through landing — студия находит нас через Google Ads / SEO / PR → signup на нашем сайте. Стандарт для B2B SaaS.
2. Partner program — рендер-студии приводят других рендер-студий за commission (см. Q37 — referral / affiliate). Multiplicative effect.
3. Marketplace listings — AppSumo / G2 / Capterra / SoftwareAdvice / PropTech маркетплейсы. Трафик + review social proof.
4. Direct sales (enterprise) — outreach к крупным агентствам, custom contracts. Высокий CAC, но высокий ACV.
5. Industry conferences — PropTech / real estate events. Expensive, но network-heavy industry.

Channel mix решения:

• 100% direct — простой, но slow growth
• Direct + marketplace — growth via reviews + SEO
• Direct + partners — leveraging network effects в rendering studio community
• Full mix — complex management, но максимальный reach

Что решить:

• Channel mix (какие channels priority, какие можно отложить)
• Partner program structure (см. Q36/Q37 — affiliate / referral / integration partner)
• Какие marketplaces priority (AppSumo = deal-hunters, G2 = enterprise research, Capterra = SMB)
• Budget allocation между каналами
• Когда запускать каждый (channel sequencing)

Типичный sequence для B2B SaaS:

1. Direct landing + SEO/content (от запуска)
2. Referral program (после первых 50 customers)
3. Marketplace listing G2/Capterra (6 месяцев после launch)
4. Affiliate program (9-12 мес после launch)
5. Channel partners / reseller (after proof of product + $100k+ MRR)

Q36 — Accessibility (WCAG) compliance

Закрывает: Design + Tech team + Legal · Связано с: Фаза 3.1 (Performance & Scale)

В чём суть: WCAG (Web Content Accessibility Guidelines) — стандарты доступности для людей с ограниченными возможностями. Compliance становится регуляторным требованием.

Регуляторы:

• EU EAA (European Accessibility Act) — обязателен с 2025-06-28 для B2C веб-сервисов. Публичные страницы проектов = B2C → попадают. Fines до €1M per violation.
• ADA (US) — не прямо требует WCAG, но суды используют как стандарт. Real estate = high-frequency ADA lawsuit target ($50-100k payouts).
• UK Equality Act 2010 — аналогично.

Что больно в нашем продукте:

• 360° panorama — screen reader не может «прочитать» walkthrough. Нужны alt-описания / текстовые альтернативы.
• Hotspots — mouse clicks OK, keyboard navigation?
• Floor plans — визуальный контент, нужны accessible descriptions.
• Цвета статусов (sand/gold палитра) — contrast ratio проверить.
• Forms — signup, onboarding, unit edit — labels, error messages для screen reader.

Уровни:

• A — базовый (alt-текст, keyboard nav)
• AA — ожидаемый стандарт для compliance (color contrast, resizable text, captions)
• AAA — строгий (редко полностью реализуется)

Что решить:

• Target уровень: AA (стандарт) или AAA (premium)?
• Timing: до пилота / до публичного запуска / отложено после EAA deadline?
• Audit: внутренний (дёшево, может пропустить) или внешний ($5-15k одноразово)?
• Automated testing в CI (axe, pa11y) — да / нет?
• Scope: публичные страницы (обязательно per EAA) / admin (B2B, меньше жёсткость)?

Риск:

• Non-compliance с EAA после 2025-06-28 = fines + lawsuits
• ADA lawsuit в US — класс-экшн обычно $50-100k settlement
• Reputation damage

Q37 — Incident communication + SLA credits

Закрывает: Legal + Ops + Finance · Связано с: Фаза 3.5 (SLO + Runbooks)

В чём суть: Мы обещаем 99.5% uptime в ToS (Фаза 1.5.1). Что происходит если не выполняем?

Две составляющие:

1. Incident communication (частично в плане):

• Status page (Фаза 3.5.3) — публичная страница с uptime и инцидентами
• Email-notifications студиям при инциденте
• Incident post-mortem — публичный пост с root cause и fix (best practice)

2. SLA credits (отсутствует в плане):

• Если упали ниже 99.5% месяца — что клиент получает?
• Стандартная B2B SaaS модель: % скидки на следующий месяц
• Cap: обычно maximum 100% (не должны платить клиенту)

Типичные структуры SLA credits:

Что решить:

• Заводим ли SLA credits вообще? (Некоторые SaaS не дают — «гарантия best effort»)
• Структура (tiered vs flat)?
• Applied автоматом при нарушении SLA или только по запросу клиента?
• Cap (max 100% или меньше)?
• Включено в Starter / Studio / Agency или только Enterprise?
• Communication policy — как сообщаем о downtime? (automated status page / manual email / both)

Legal implications:

• SLA credits = часть ToS. Должны быть чётко прописаны в Фазе 1.5.1
• В некоторых юрисдикциях SLA credits = гарантия → имеет юридические последствия

Q38 — White label depth

Закрывает: Product team + Marketing + Legal · Связано с: Фаза 1.4.2 (Pricing) + Фаза 4.3.6 (Customization)

В чём суть: Сколько VV-бренда видит конечный покупатель квартиры на странице студии? Spectrum от heavy branded до полной invisibility.

Уровни white-label:

Где ещё может всплывать brand:

• 360° walkthrough UI — кнопки / controls с нашим стилем?
• Email-уведомления покупателю — от студии или от @volumevision?
• Domain (studio.com vs studio.offplan.online) — covered уже в custom domain
• Meta tags / Open Graph (при share в WhatsApp/LinkedIn)
• Hard-coded footer copy?

Typical B2B SaaS pattern:

• Starter tier — «Powered by» обязательно (как Notion free)
• Studio tier — убирается
• Agency tier — убирается + кастомизация meta tags
• Enterprise — полная invisibility + custom domain + custom emails

Что решить:

• Policy per tarif — на каком tier'е убираем VV-брендинг?
• Scope — где видно брендинг (walkthrough / emails / meta / footer / все?)
• Mandatory vs removable — на базовом plan вообще нельзя убрать или можно за доплату?
• Privacy policy линк — ведёт к студии или к VV? (связано с DPA двухуровневой структурой)

Business trade-off:

• Branded visible = organic leads (покупатель гуглит VV) → но меньше premium-ощущение для студий
• Invisible = студия premium → но мы теряем passive marketing

Legal:

• DPA уже двухуровневая (студия = controller, VV = processor) — это правильно независимо от брендинга
• Privacy Policy линк от студии к её собственной privacy policy — стандартно

Appendix F — Связанные файлы

• plans/launch-plan-v2.md — предыдущая версия (архив)
• plans/launch-plan-v2.html — предыдущая HTML-версия
• docs/launch-plan-v3-visual.html — визуальный appendix v3 (admin panel concept + v4 mockup)
• docs/ux-audit-vv-admin-2026-04-23.md — UX-аудит (CONV-7)
• docs/admin-panel-v4.html — исходный v4 mockup (референс для appendix)
• plans/agenda-2026-04-27.md — agenda на неделю + синтез разговора с Ромой (источник ревизии 3.1)
• docs/sessions/CONV-3.md → CONV-9.md → CONV-10.md — история обсуждений
• Notion Learnings DB — 10+ Learnings по теме, использованных в плане

Appendix G — Changelog

v3.1 — 2026-04-27 (CONV-10)

Источники изменений:

• Звонок Сергея с Ромой 2026-04-24 (синтез в plans/agenda-2026-04-27.md)
• Видео-звонок с Надеждой (Dubai sales manager) 2026-04-23 (transcript в session CONV-10)

Структурные изменения Стадии 1

Перенумерация фаз (логический порядок приоритетов):

• 1.1 был Security → стал 1.7 (понижен, базовый уровень для tech team)
• 1.6 был Visual Redesign → стал 1.1 (Priority #1 — брендбук разблокирует всё визуальное)
• 1.3 был Admin UX → стал 1.4 (понижен, нужна верификация Ильёй real prod issues)
• 1.4 был Payments → стал 1.5
• 1.5 был Legal → стал 1.6
• 1.2 (Onboarding) — позиция сохранена, но содержание значительно расширено

Новые фазы:

• 1.3 — MCP Server Wrapper (перенесён из 4.1.5 в Стадии 4). Сергей: «Без MCP не запускаться.» Две итерации: read-only (Стадия 1) + read+write (Стадия 1 или 2 — зависит от эстимейта).
• 1.8 — Sales-app UX redesign (новая, по фидбеку Надежды). Filter-based selection вместо хотспотов. Conditional: если сложно → Стадия 2 или 3. MVP (1.8.1 фильтры) должен остаться в Стадии 1.

Расширения существующих фаз:

• 1.2.1 (Signup): добавлена 5-уровневая архитектура tenant access (VV master / studio admin / employees / dev client / dev agents)
• 1.2.2 (Subdomain): переписано — поддомены per-project, не per-studio
• 1.2.3 (Custom domain): переписано — для проектов, не студий
• 1.2.4 (Wizard): убран project type field, убран Slack invite, убран Skip (wizard обязателен)
• 1.2.5 (Demo project): не выбирать заранее — сделать оба варианта через Claude Design + Figma
• 1.2.6 (Email sequence): отложено в Стадию 3. До пилота — слишком рано
• 1.2.7 (Team management): значительно расширено — 5 уровней доступа, full permission model, требуется отдельная спецификация перед build
• 1.4 (Admin UX, was 1.3): 🟡 понижено в приоритете. Большинство багов — dev-env. Нужна верификация Ильёй
• 1.5.8 (Flat-fee tier — NEW): добавлено по фидбеку Надежды. Альтернатива subscription для клиентов "настроили проект, дальше не меняем"
• 1.7 (Security, was 1.1): 🟡 понижено в приоритете. Базовый уровень — checklist для tech team

Структурные изменения Стадии 4

• 4.1.5 (MCP wrapper) — перенесён в Стадию 1 как Фаза 1.3. Stub оставлен для backwards reference.

Изменения в Executive Summary

• Стадия 1: 5 фаз → 8 фаз; ~25 подзадач → ~40 подзадач
• Стадия 4: 5 фаз → 4 фазы; ~20 подзадач → ~15 подзадач
• Матрица критичности обновлена с учётом перенумерации

Что осталось решить (для следующей ревизии после звонка с Ильёй)

• Эстимейт 1.3.3 (MCP read+write) — определит остаётся ли в Стадии 1 или переезжает в Стадию 2
• Эстимейт 1.8.x (Sales-app UX) — какие подзадачи реально в Стадии 1 vs Стадия 2/3
• Архитектурный feasibility multi-level access (1.2.7) — готова ли существующая БД
• Backend upload formats (1.4.4) — может стать неактуальной если tech team скоро выкатит
• 1.4 (Admin UX) — какие баги real prod, какие dev-only

CRM integration depth — backlog item (не Стадия 1)

Из разговора с Надеждой выявлена глубокая CRM-интеграция (Microsoft Dynamics): отслеживать какие юниты показывались каким клиентам, при какой цене, в какой день — критично, потому что цены растут со строительной готовностью. Илья оценил ~$100k. Не Стадия 1, но data model для "presentation events" нужно спроектировать заранее. Добавить в backlog для Стадии 2.

v3.0 — 2026-04-24 (CONV-9)

Первая версия плана: 4 стадии, 21 фаза, ~110 подзадач. Three artefacts: canonical markdown, full HTML for reading, visual appendix HTML. Создан после звонка Сергея с Ильёй.

Конец документа.

Этот план — source of truth в git. Notion-зеркало — для обсуждения и комментариев. Если две версии расходятся — git выигрывает.