Pet · Продукт · 0 → 1 · 2026

Lumos — сказки на ночь

Собрал сквозной кликабельный прототип всей воронки (лендинг → персонализация → генерация → оплата → серия с озвучкой) и откалиброванный промпт-движок. Готовится к запуску.

TL;DR

Сквозной прототип сказки-ритуала на ночь — от Discovery и бренд-системы до кликабельного прототипа с озвучкой и спроектированной операционной админкой

  • 01Спроектировал продукт от Discovery и AJTBD-сегментов до RAT, PRD и воронки с зашитой аналитикой
  • 02Собрал кликабельный сквозной прототип (vanilla JS, без сборки): лендинг → форма → бесплатный эпизод → мост в Telegram → мок-оплата ЮKassa → серия из 5 + апсейл
  • 03Спроектировал Story System и Admin Product OS — систему контроля качества, безопасности и операций для AI-генерации контента

ПЛАТФОРМА

Петпроект (соло-запуск)

РОЛЬ

Продукт · дизайн · разработка

ПЛАТФОРМА

Claude Code · Vanilla JS · Node · Telegram

СРОК

2026

СТАТУС

В работе, pre-launch

Идея

Дети 3–7 лет часто боятся темноты, и вечерний ритуал превращается в борьбу. Гипотеза Lumos: персонализированная серия сказок на 1–2 недели, где главный герой похож на ребёнка и постепенно справляется со страхом — не разовая сказка, а вечерний ритуал. Личная цель — протестировать навык сольного запуска цифрового продукта и довести его до портфолио-кейса: от исследования и гипотез до работающего прототипа.

Discovery, рынок и AJTBD-сегменты

Перед тем как писать код, я провёл discovery: разобрал рынок персонализированных детских книг и AI-сказок (включая зарубежные продукты вроде Loona и Tinker Tales), описал Big Job родителя — «помочь ребёнку спокойно и предсказуемо закончить день» — и разложил его на 5 ключевых Jobs To Be Done. На основе AJTBD выделил сегменты родителей: от «вечерний хаос, нужен быстрый ритуал» до «ищу развивающий контент с моралью без нотаций». Это исследование позже определило не только функциональность, но и тон коммуникации — отказ от языка «AI-генератора» в пользу языка «семейного ритуала».

RAT → PRD → воронка с аналитикой

Ключевые гипотезы я проверил через Riskiest Assumption Test до написания продуктового кода: готовы ли родители платить за персонализацию, достаточно ли «бесплатного эпизода», чтобы показать ценность, и работает ли формат Telegram как канал доставки. На основе RAT собрал PRD и трёхступенчатую воронку: web-лендинг → бесплатный эпизод → мост в Telegram → платная серия. В прототип сразу зашил события аналитики (cta_click, free_episode_opened, audio_play, lead_bridge_click, checkout_started, payment_success, episode_opened), чтобы с первого дня видеть, где теряются пользователи.

Прототип: лендинг → форма → серия → озвучка

Собрал кликабельный сквозной прототип на чистом vanilla JS без сборки: лендинг с офером, форма персонализации (имя, возраст, любимая игрушка, тема страха), бесплатный эпизод с озвучкой, мост в Telegram-бота, мок-оплату через ЮKassa и доступ к полной серии из 5 эпизодов с апсейлом следующей темы. Прототип работает полностью на моках — без подключения реального AI API и платёжного шлюза, — но воспроизводит реальный пользовательский путь от первого касания до повторной покупки.

Промпт-движок и эталонная демо-серия

Чтобы прототип ощущался живым, а не заглушкой, я собрал и откалибровал промпт-движок генерации сказок: структура входных слотов (имя, возраст, тема, любимая игрушка, друзья), правила длины и ритма текста, озвучка ~5 минут на эпизод. На этой основе записал эталонную демо-серию из 5 эпизодов про девочку Машу, которая постепенно справляется со страхом темноты — она используется как референс качества для будущей AI-генерации и как живой пример в самом прототипе.

Story System: от генератора к системе ритуалов

По мере проработки контента стало понятно, что одного промпт-движка недостаточно — нужна система. Я спроектировал Story System: формулу эпизода (узнавание → мягкая дистанция → маленькое испытание → действие героя → тёплое возвращение), структуру серии из 5 вечеров с разными ролями, возрастные правила для 3–4, 5–7 и 8–10 лет, поля персонализации (обязательные / усиливающие / чувствительные) и метод «мораль без морализаторства» с примерами до/после. Отдельно описал safety-правила: запрещённые обещания, «красные зоны» тем и формулу мягкого отказа, а также 10-критериальный quality rubric с минимальным порогом 16/20 и обязательными 2/2 по безопасности и IP.

Admin Product OS: операционная система продукта

Чтобы AI-native продукт можно было реально эксплуатировать, я спроектировал Admin Product OS — операционную систему продукта поверх Story System. Информационная архитектура: Overview, Funnel, Users, Child Profiles, Topics, Series, Episodes, Safety Review, Payments, Support, Experiments, Operations. Прописал статусы контента/пользователей/рисков, роли (Owner, Content Editor, Safety Reviewer, Support, Agent), UI-принципы (десктоп-first, таблицы вместо карточек, сдержанная цветовая кодировка по функции) и поэтапный rollout — от обновления текущей админки без изменений в БД до подключения дашборда метрик, контент-операций и платежей/поддержки.

Метрики, инсайты, дальше

Главный инсайт: ценность продукта определяется не качеством генерации текста, а ощущением персонального вечернего ритуала — и поэтому AI должен оставаться «под капотом». Текущий статус — рабочий кликабельный прототип на моках с зашитой аналитикой, эталонной демо-серией и спроектированными Story System и Admin Product OS. Дальше: подключить реальный AI API и платёжный шлюз, реализовать обновлённый UI клиента, бота и Mini App по бренд-гайдам и запустить первую когорту с целью 5–15 продаж в неделю.

Похожая задача — обсудим.