Наведите на плашку — полное описание и пункт ТЗ. Номер плашки (LB-01 …) удобен в переписке.
День 0 — день получения согласования roadmap от Yunus и Fatih. Все недели на диаграмме считаются от этого дня, а не от даты файла. Если согласование приходит сразу, 10-я неделя приходится примерно на конец октября; если позже — те же недели сдвигаются.
На неделе 0 фиксируем домен продукта (golaunchbase.com) и правило: клиент никогда не видит имя CorpNet. Партнёры исполнения остаются за кадром.
Исходное ТЗ: подачи Phase 1 идут через CorpNet как тихого партнёра исполнения. Публичная страница CorpNet API описывает REST, JSON, Bearer token, создание заказа, документы, опрос статуса (вебхуков пока нет), RFI, отмену.
На неделе 0 Yunus и Fatih отправляют с корпоративной почты LaunchBase запрос документации (их interest / partner form). Цель — получить техническое описание API, чтобы спроектировать адаптер. Это не коммерческое закрытие и не старт боевых ключей. Staging-ключи подключаем позже, когда продукт уже кликабелен на моках (LB-12).
Тестирование безопасностиЯркий конец плашки: документацию читаем, ключи в чат и в репозиторий не кладём. Запрос уходит только с корпоративной почты LaunchBase.
ТЗ требует сравнение штатов (налоги, приватность, стоимость, нагрузка compliance) и рекомендации по типу (LLC, S-Corp, C-Corp, Nonprofit, Professional Corp) с визуальными подсказками, а не стеной юридического текста. Сначала образование: пользователь понимает почему, а не только куда кликнуть.
Делаем гид, который выдаёт короткое «почему этот штат / почему этот тип» и CTA начать регистрацию. Та же идея, что на публичном сайте («where should you form», «which structure»), но уже как рабочий шаг продукта.
Тестирование безопасностиПромпты помощника без PII. Секреты и ключи на фронте не живут. Клиент не уходит на чужой домен.
ТЗ: чистый пошаговый intake, вопросы меняются от типа компании, штата и цели бизнеса; валидация в реальном времени и прогресс. Пакеты как на golaunchbase.com: Basic / Standard / Premium, state filing fees проходят по себестоимости.
Клиент всё время остаётся на LaunchBase. Он не заполняет форму CorpNet и не заходит на сайт Secretary of State.
Тестирование безопасностиSSN/ITIN и паспорт не пишем в логи и аналитику. Поля только по HTTPS. Проверяем, что анкета не утекает на чужой сайт.
ТЗ перечисляет каталог, который потом нужно уметь заказывать без перестройки сайта: поиск/резерв имени; 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 бьют в мок. LaunchBase владеет стабильными методами (создать заказ, получить заказ, документы, статус). Тонкий адаптер потом меняет MockCorpnet на LiveCorpnet. Экраны не меняются. Статус живёт на заказе LaunchBase: received, paid, queued, submitted, RFI, filed, rejected — needs staff, documents ready. Клиент видит простой таймлайн; сотрудник — маршрут, ошибки и PII.
Тестирование безопасностиМок только на вымышленных людях. PII заказа не в браузере и не в логах. Клиент не видит имя CorpNet и внутренний маршрут.
Публичной таблицы «у этих штатов есть API регистрации» нет. Search API — это не create-LLC API. Поэтому дефолт для всех пятидесяти штатов — CorpNet: так закрываем страну без пятидесяти интеграций. Direct значит: LaunchBase на этом заказе обходит CorpNet, потому что найден реальный канал штата (портал filer / API) и это имеет смысл по объёму.
Сотрудник может переключить штат. Заявки в полёте остаются на своём маршруте; новые идут по новому свитчу. Мы не переводим все пятьдесят штатов на Direct. Длинный хвост может остаться на CorpNet. Если канал Direct недоступен — штат обратно на CorpNet. Письмо в штат — не канал подачи.
Тестирование безопасностиСвитч маршрута — только роль staff/admin. Чужой сотрудник не двигает чужие заявки. Клиент по-прежнему не видит партнёра.
ТЗ называет кабинет главным отличием, в духе compliance-платформ класса Harbor, но упрощённо для не-юристов: статус регистрации, поданные документы, registered-agent, ближайшие дедлайны, обязательства штата, история compliance и audit trail.
Демо недели 4: закончить анкету → тестовая/мок-оплата → таймлайн двигается → Articles и письмо EIN появляются как файлы. Очередь сотрудника фильтрует по штату, маршруту и статусу и может пушить мок-статус. Имя CorpNet в клиентском UI не появляется.
Тестирование безопасностиКлиент видит только свои файлы. Staff/admin разделены. Документы не отдаются чужому аккаунту. Имя CorpNet в клиентском UI не всплывает даже в ошибке.
Публичного интернет-списка 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-ключи, мы заменяем MockCorpnet на LiveCorpnet. Тот же UI LaunchBase. Аутентификация — Bearer token от партнёра; статус опрашивается. Документацию для этого запрашиваем в LB-02.
Так получаем реальные подачи по пятидесяти штатам без пятидесяти самодельных Direct API. Direct включается только если штат реально выдал канал (LB-08 / LB-09); иначе штат остаётся на CorpNet. Не обещаем API штата, которого нам не дали.
Тестирование безопасностиBearer token только на сервере. Staging и production не смешиваем. Ключи не в фронте, не в git, не в логах.
В заказах будут имена, адреса, ownership, иногда SSN/ITIN или сканы паспорта, и PDF регистрации. HTTPS; роли client / staff / admin; PII не в фронтенде и не в логах; файлы шифруются at rest; аудит view / generate / send; ключи только на сервере; исходящая почта через корпоративный API. В прототипах — вымышленные люди.
Приложение на поддомене LaunchBase (например app.golaunchbase.com). Бэкапы и прод-проход до живых ключей CorpNet.
Тестирование безопасностиЭто финальный security pass перед живыми ключами: HTTPS, роли, шифрование at rest, бэкапы, аудит view/generate/send, 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, аудит. После этого — операционный продукт.