День 0 = 20 августа 2026 (согласование получено). Недели ниже — календарные от этой даты. Клик по плашке открывает чеклист, отметки и подробные заметки (сохраняются в этом браузере).
Наведение — кратко · клик — прогресс. Коды LB-01 … LB-22 удобны в переписке.
День 0 зафиксирован: 20 августа 2026 — согласование roadmap получено от Yunus и Fatih. Все недели на диаграмме — календарные от этой даты. 10-я неделя — конец октября / начало ноября; Harbor и Skyrocket — до конца декабря.
На неделе 0 фиксируем домен продукта (golaunchbase.com) и правило: клиент никогда не видит имя CorpNet. Партнёры исполнения остаются за кадром.
Исходное ТЗ: подачи Phase 1 идут через CorpNet как тихого партнёра исполнения. Публичная страница CorpNet API описывает REST, JSON, Bearer token, создание заказа, документы, опрос статуса (вебхуков пока нет), RFI, отмену.
Плашка закрыта: Yunus и Fatih отправили запрос с корпоративной почты LaunchBase; Morgan ответил доками API / sandbox (apidocs.corpnet.com). Контракт адаптера набросан как MockCorpnet. Staging-ключи остаются LB-12 — после кликабельного мока и LB-13. Это не коммерческое закрытие.
Тестирование безопасностиЯркий конец плашки: документацию читаем, ключи в чат и в репозиторий не кладём. Запрос уходит только с корпоративной почты LaunchBase.
ТЗ требует сравнение штатов (налоги, приватность, стоимость, нагрузка compliance) и рекомендации по типу (LLC, S-Corp, C-Corp, Nonprofit, Professional Corp) с визуальными подсказками, а не стеной юридического текста. Сначала образование: пользователь понимает почему, а не только куда кликнуть.
На стенде: кликабельный гид в overlay (Get Started) — «почему этот штат / почему этот тип» и CTA. Плашка этой фазы сдана как мок. БД и аккаунты — LB-13; ключи CorpNet — LB-12. Показ заказчику — LB-21.
Тестирование безопасностиТолько мок: вымышленные сценарии, overlay на демо-домене. Реальные роли, изоляция PII и БД — LB-13. Секреты на фронт не кладём.
ТЗ: чистый пошаговый intake, вопросы меняются от типа компании, штата и цели бизнеса; валидация в реальном времени и прогресс. Пакеты как на golaunchbase.com: Basic / Standard / Premium, state filing fees проходят по себестоимости.
На стенде: динамическая анкета под брендом LaunchBase (клиент не уходит на CorpNet / SOS). Плашка сдана как мок: пошлины штата — copy. Живой продукт — LB-13. Показ заказчику — LB-21.
Тестирование безопасностиНа моке поля анкеты живут в браузере (localStorage). Боевая изоляция SSN/ITIN, роли и HTTPS-продукт — LB-13.
ТЗ перечисляет каталог, который потом нужно уметь заказывать без перестройки сайта: поиск/резерв имени; LLC, C-Corp, S-Corp, Nonprofit, Professional Corp; articles; initial reports; EIN; DBA; S-election; foreign qualification; лицензии; annual и bi-annual reports; registered agent; amendment; conversion; reinstatement; dissolution; certified copies; rush; payroll tax registration.
Пока нет ключей, и Direct, и CorpNet бьют в мок. На стенде: методы заказа, каталог Phase 1, таймлайн. Плашка сдана; данные заказа пока в localStorage. Живой CorpNet — LB-12 после security pass LB-13.
Тестирование безопасностиМок только на вымышленных людях. В этом демо заказ лежит в браузере. Клиент не видит имя CorpNet. Реальная изоляция PII / БД / аккаунты — LB-13.
Публичной таблицы «у этих штатов есть API регистрации» нет. Search API — это не create-LLC API. Поэтому дефолт для всех пятидесяти штатов — CorpNet: так закрываем страну без пятидесяти интеграций. Direct значит: LaunchBase на этом заказе обходит CorpNet, потому что найден реальный канал штата (портал filer / API) и это имеет смысл по объёму.
На стенде: таблица 50 штатов + DC, свитч без логина (god-mode). Заявки в полёте не прыгают. Это не живые Direct-каналы (LB-08 / LB-09) и не роли staff (LB-13).
Тестирование безопасностиНа моке свитч открыт через god-mode, не через логин. Реальные роли staff/admin и изоляция заявок — LB-13. Клиент не видит партнёра.
ТЗ называет кабинет главным отличием, в духе compliance-платформ класса Harbor, но упрощённо для не-юристов: статус регистрации, поданные документы, registered-agent, ближайшие дедлайны, обязательства штата, история compliance и audit trail.
На стенде недели 4: анкета → мок-оплата → таймлайн → фейковые Articles / EIN. Кабинет читает localStorage, staff — god-mode. Плашка сдана как мок. Командный центр Harbor — LB-16; auth/БД — LB-13.
Тестирование безопасностиНа моке нет аккаунтов: кабинет не изолирует «своё». Имя CorpNet в клиентском UI не показываем. Реальные роли client/staff/admin и БД — LB-13.
Плашка недели 3: кликабельный стенд работает на телефоне, не только на десктопе. В шапке остаются My cabinet и Get Started; гамбургер открывает How It Works / Entity Types / Top States / Pricing. Карточка статуса в герое не прячется (на живом golaunchbase.com она скрыта до 1024px).
My cabinet — дашборд на один экран, без длинного скролла. Десктоп: две колонки (статус + next/услуги). Телефон: вкладки Status / Next up / Order.
Тестирование безопасностиТот же мок, что LB-07: localStorage, без аккаунтов. Только вёрстка. Живая изоляция — LB-13.
Показать кликабельный стенд (гид, анкета, мок-заказ, кабинет, god-mode staff). Получить письменное OK, что экраны и поток приемлемы. Это не выкладка на golaunchbase.com — живой путь остаётся LB-13, затем LB-12.
Плашки LB-03–07 уже закрыты как мок-фаза. LB-21 — отдельная галочка «заказчик посмотрел».
Тестирование безопасностиПриёмка — про экраны. Боевые ключи, PII и роли не входят в этот тикет; это LB-13 до LB-12.
Публичного интернет-списка formation API не существует. Gregory ищет на сайтах Secretary of State: filings, developer/API/XML/bulk и программы registered filer. Типичные находки: только человеческий портал, PDF, API поиска компаний или «partner program — напишите сюда».
Старт разведки — штат Флорида: это пример, который мы разобрали на первом созвоне по Microsoft Teams (сайт штата Флориды). Дальше — другие штаты, которые есть на golaunchbase.com. Это внутренняя таблица маршрутов, не пятьдесят живых интеграций. Идёт параллельно с мок-продуктом, не блокирует CorpNet.
Тестирование безопасностиТаблица маршрутов внутренняя: не публикуем наружу. В заметках нет клиентского PII и нет ключей.
Где дипсерч (LB-08) нашёл реальную дверь, официальные запросы filer/API идут от американской компании LaunchBase. Штаты почти никогда не выдают production-доступ частному разработчику. Gregory готовит текст письма и список адресатов. Отправляют Yunus и Fatih — с корпоративной почты LaunchBase.
Не рассылаем пятьдесят писем в первый день. Только штаты, где дверь нашлась. Кто ответил «да» — позже может получить свитч Direct (LB-06). Остальные остаются на CorpNet.
Тестирование безопасностиПисьмо уходит только с корпоративной почты LaunchBase. В черновике нет лишнего PII. Вложения и адресатов сверяем до отправки.
В ТЗ Federal Tax ID (EIN) входит в Phase 1. CorpNet часто умеет закрывать EIN. На первом созвоне по Microsoft Teams, на примере сайта штата Флориды, обсудили дыру: у части госуслуг нет API. Первый шаблон — IRS Form SS-4 (заявка на EIN) в контексте Florida for-profit corporation. SS-4 федеральная; «Florida» — настройка сущности, не другая форма IRS.
Поток: структурированные поля в LaunchBase → заполнить официальный PDF → превью и хранение на заказе → отправка через защищённый корпоративный email API (не личный ящик) → статусы PDF generated, sent, awaiting EIN. Входящую госпочту не парсим как систему учёта. Отказы уходят в needs-staff-review. Клиент может начать поля; сотрудник всегда проверяет.
Тестирование безопасностиPDF с EIN шифруется. Исходящая почта только через корпоративный API, не с личного ящика. Аудит: кто сгенерировал и кто отправил.
На первом созвоне по Microsoft Teams, на примере сайта штата Флориды, обсудили: такие сайты и PDF есть не только у Флориды. После SS-4 тот же движок маппинга берёт следующие официальные PDF — Florida articles или annual report, затем PDF других штатов — без нового продукта каждый раз.
По-прежнему не «отправить штату email как подачу». По-прежнему аудит: кто сгенерировал и кто отправил файл.
Тестирование безопасностиТот же проход, что у SS-4: шифрование файла, корпоративная почта, аудит generate/send. Личный ящик не используется.
Когда CorpNet выдаёт staging-ключи и LB-13 пройден (хостинг, БД, auth, security pass), заменяем MockCorpnet на LiveCorpnet. Тот же UI LaunchBase. Аутентификация — Bearer token от партнёра; статус опрашивается. Документацию для этого получили в LB-02.
Так получаем реальные подачи по пятидесяти штатам без пятидесяти самодельных Direct API. Direct включается только если штат реально выдал канал (LB-08 / LB-09); иначе штат остаётся на CorpNet. Не обещаем API штата, которого нам не дали.
Тестирование безопасностиBearer token только на сервере. Staging и production не смешиваем. Ключи не в фронте, не в git, не в логах.
Мок на overlay и localStorage нельзя выкладывать как продукт на golaunchbase.com. LB-13: приложение на app.golaunchbase.com (не overlay на маркетинговом сайте); база данных заказов вместо localStorage; логины client / staff / admin; PII не во фронте и не в логах; файлы at rest; бэкапы; аудит view / generate / send; ключи только на сервере.
Прод security pass подписывается до живых ключей CorpNet (LB-12). В прототипах — вымышленные люди.
Тестирование безопасностиЭто security pass перед LB-12: хостинг, БД, auth, шифрование, бэкапы, аудит, PII не в логах.
В этом срезе ИИ значит: почему этот штат/тип (сначала образование), проверка дыр в анкете, клиентские формулировки статусов, черновики для сотрудника. Позже, на Harbor: тексты напоминаний и сортировка очереди.
Модель не подаёт документы в штат и не заменяет CorpNet или PDF. Подача — это API, официальный PDF или человек.
Тестирование безопасностиВ промпт не попадают SSN и ключи. Модель не имеет права отправить filing. Ответы ИИ не пишут PII в логи.
ТЗ Phase 2: после регистрации компания живёт дальше. Harbor — тихий партнёр compliance, как CorpNet для filings. Клиент по-прежнему видит только LaunchBase.
Неделя 11: Yunus и Fatih отправляют с корпоративной почты LaunchBase запрос документации Harbor API. Gregory читает контракт методов и проектирует адаптер. Боевые ключи — в LB-17, после мока в кабинете.
Тестирование безопасностиКак в LB-02: запрос только с корпоративной почты. Ключи Harbor не кладём в чат и в репозиторий.
По ТЗ кабинет должен показывать: календарь обязательств штата, ближайшие дедлайны, напоминания, алерты по штату, историю compliance. Для холдингов и фаундеров — несколько компаний в одном аккаунте (multi-entity).
Как: данные компании после formation (штат, тип, дата регистрации) → правила штата + ответ Harbor (сначала мок) → карточки дедлайнов в том же кабинете LB-07. Клиент видит «annual report due May 1»; сотрудник видит очередь просрочек. ИИ (LB-14) пишет понятный текст напоминания, но не файлит.
Тестирование безопасностиКлиент видит дедлайны только своих компаний. Staff — по роли. Чужой EIN в чужом кабинете не появляется.
Неделя 12: адаптер MockHarbor — те же методы LaunchBase (календарь компании, список обязательств, отметить выполненным). Экраны LB-16 не меняются.
Недели 13–14: когда Harbor выдаёт ключи — LiveHarbor. LaunchBase опрашивает статусы и кладёт их в кабинет. Если ключей ещё нет, кабинет остаётся на моке с правилами штатов — продукт не стоит. Готово, когда клиент видит реальные даты по своей компании, а не «Later».
Тестирование безопасностиКлючи Harbor только на сервере. Мок не содержит боевых данных. Staging и production не смешиваем.
Долгое видение ТЗ: LaunchBase — регистрация и юридический жизненный цикл; Skyrocket — бухгалтерия, payroll, налоги, прогнозы, книги. Один логин, одна экосистема, от идеи до налогов.
Недели 15–16: после formation клиент в кабинете LaunchBase видит шаг «открыть учёт / налоги». По этому шагу создаётся карточка компании в Skyrocket (название, штат, EIN, владельцы, документы из LB-07). Один аккаунт. Не отдельный «ещё один сайт», на который надо заново регистрироваться.
Тестирование безопасностиОдин логин не смешивает чужие компании. Передача карточки только внутри экосистемы LaunchBase → Skyrocket, не наружу.
По ТЗ финансовый контур: bookkeeping / accounting, payroll, налоговые декларации, проекции. Это уже ядро практики Yunus; задача продукта — не изобрести бухгалтерию с нуля, а дать клиенту LaunchBase тот же контур без разрыва.
Как: intake «какие счета / какой payroll / какой штат налога» → статус в кабинете (книги ведутся, payroll зарегистрирован, налоговая декларация в работе) → файлы и статусы рядом с formation-документами. Сначала мок-пайплайн, чтобы экраны и статусы были готовы до живого контура.
Тестирование безопасностиПоля payroll и налогов — PII: не в логах, не на фронте сверх нужного, доступ по роли.
Когда внутренний контур Skyrocket (учёт / payroll / tax) готов принимать компании, адаптер переключается с мока на live — тот же приём, что LB-12 для CorpNet и LB-17 для Harbor.
Готово, когда компания, зарегистрированная в LaunchBase, видна в Skyrocket с EIN и документами, клиент ходит в одном логине, а сотрудник ведёт книги и налоги не в отдельной таблице. После недели 18 это уже операционный продукт, не «фаза когда-нибудь».
Тестирование безопасностиФинальный security pass всего контура LaunchBase → Skyrocket: роли, ключи на сервере, PII, аудит. После этого — операционный продукт.