2 рубля за сказку с озвучкой: как я считал юнит‑экономику AI‑продукта на коленке

Зачем и почему

Немного о себе — более двадцати пяти лет в ИТ, разрабатывал на С++ и Java, но с 2015 года ушел в менеджмент и сейчас руковожу командой разработки в банке. Сам код руками почти не пишу — в основном процессы, ревью, планирование. На основной работе использовать ИИ нельзя: закрытый контур, никакого доступа во внешний интернет для моделей.

Идея была простая: сделать что‑то небольшое в свободное время, что возможно в каком‑то будущем превратится в параллельный источник дохода, не требуя от меня много личных часов. Остановился на Telegram‑боте, который генерирует персонализированные сказки на ночь: родитель задаёт участников, обстановку, тему — бот пишет сказку, при желании озвучивает.

Сразу оговорюсь: это не история успеха. Проект сейчас на стадии тестирования монетизации, и не факт, что он вообще взлетит даже после рекламы среди более широкой аудитории. Но процесс разработки — с реальными цифрами, граблями и решениями — мне кажется интереснее, чем ждать финального результата, чтобы об этом написать.

Отдельная причина, почему я вообще сел за это: я впервые системно попробовал делегировать реализацию AI‑агенту (Claude Code), а не писать код сам. Опыта с агентной разработкой у меня было буквально два дня, в течении которых я сделал простое Андроид приложение. Ну а дальше расскажу, как это выглядело изнутри.

Технические решения и почему

Стек получился такой:

— Java + Spring Boot — на бэкенде, потому что это то, что я знаю лучше всего, и не было причин учить новый язык ради pet‑проекта на вечерах.

— PostgreSQL — для MVP развёрнут в Docker на той же VPS ^[1], без managed‑сервиса. Сознательное упрощение: для нагрузки на старте это избыточная сложность, которую всегда можно добавить позже, если понадобится.

— Telegram Bot API — очевидный выбор для российской аудитории и минимального порога входа для родителей (не нужно ставить отдельное приложение).

— GigaChat как LLM для генерации текста сказок.

— Yandex SpeechKit — для озвучки (женский голос рассказчика).

— Yandex Object Storage — хранение готовых аудиофайлов.

— Хостинг ^[1] — Timeweb Cloud, обычный VPS ^[1].

Репозиторий на GitHub, с автодеплоем на VPS ^[1] через GitHub Actions при пуше в main — это единственное, что я настроил с самого начала, остальное сознательно упрощал — нет никаких rolling updates, оркестрации и так далее. Про надежность и доступность тут речи не шло.

Роль Claude Code в разработке

Здесь, наверное, самая интересная часть для тех, кто пишет код руками двадцать лет, а потом решает этого не делать.

Я собрал план проекта (user stories, user journey, activity diagram, WBS) в Notion, продублировал его в PLAN.md в папке проекта — специально для Claude Code, чтобы у него был контекст. Дальше работал так: беру один пункт WBS, отдаю Claude Code, он реализует, я смотрю diff, подтверждаю или прошу переделать, только после этого переходим к следующему пункту.

Это медленнее, чем дать агенту сразу целый эпик и уйти пить кофе, зато полностью контролируемо — что мне, как человеку, который двадцать лет отвечает за качество чужого кода в продакшене, было психологически важно на старте. Условно один цикл выглядел так: прошу добавить в бота предопределённые обстановки для сказки (лес, космос, подводное царство и тому подобное), Claude Code предлагает структуру enum + маппинг в промпт, я прошу уточнить, как это ляжет на существующую схему БД, он поправляет, я подтверждаю миграцию.

Честно: за первые дни я не столько «программировал через агента», сколько заново учился формулировать задачи так, чтобы не пришлось трижды переспрашивать. Это отдельный навык, и он не приходит автоматически из двадцати лет опыта написания кода руками.

Неожиданности и грабли

1. GigaChat плохо держит числовую цель по длине. Изначально длительность сказки задавалась в минутах (5 / 10 / 15) — расчёт был на то, что модель будет ориентироваться на примерное количество слов. На практике GigaChat довольно упрямо держится «естественной» длины около 450–700 слов почти независимо от инструкции про длительность. Пришлось переходить с минут на количество препятствий/эпизодов в сюжете (1–2 / 3–4 / 4–5) под названиями «Короткая / Средняя / Длинная» — модели оказалось проще следовать структурной инструкции («добавь два препятствия»), чем абстрактной числовой цели («уложись в 10 минут»). Реальные измеренные длительности после этого: короткая — 3:20, средняя — 4:40, длинная — 6:32.

2. Риск очереди при росте пользователей. Бесплатный тариф GigaChat (Freemium) обрабатывает запросы в один поток одновременно. Сказки на ночь по своей природе запрашиваются в довольно узкое вечернее окно — если параллельно обратятся несколько семей, начнётся очередь. Решение — переход на тариф GigaChat Business (до 10 потоков, пакеты от 5 млн токенов, уже для коммерческого использования), но это требует оформления самозанятости, которое я запустил отдельно. Порог принятия решения о переходе я определил заранее и формально: p95 времени обработки больше 60 секунд.

3. Модерация текста вторым LLM‑проходом. Изначально не закладывал это в MVP, но по ходу разработки стало понятно, что для контента, который читают детям, одного прохода генерации недостаточно — добавил отдельный проход, который проверяет сгенерированный текст перед отправкой пользователю. Это не опциональная фича, а то, без чего продукт для этой аудитории просто нельзя было выпускать.

Экономика

Посчитал себестоимость сказки — это оказалось приятно воспроизводимо: два независимых замера для ~4-минутной озвученной сказки сошлись почти один в один — 2,07 ₽ и 2,0664 ₽. Разбивка по второму замеру: GigaChat — 0,8712 ₽ (42%), Yandex SpeechKit (TTS) — 1,1952 ₽ (58%). То есть озвучка сейчас дороже самой генерации текста — не то, что я интуитивно ожидал в начале.

Данных по себестоимости 10- и 15-минутных сказок пока честно нет — оба замера, которые я делал, по факту оказались на ~4 минуты (один из них ошибочно назвал «15-минутным» — заметил только при пересчёте).

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

Текущий статус и план раскрутки

На данный момент бот развёрнут и работает на боевом VPS ^[1], есть тесты, модерация текста вторым проходом, приватный эндпоинт аналитики. Оформил самозанятость на себя лично, сейчас жду одобрения заявки в ЮKassa и подключения ЭДО.

План раскрутки — намеренно поэтапный, без открытой рекламы на старте: сначала расширение личного круга (10–15 знакомых семей), затем один небольшой знакомый чат, и только потом — более широкий канал. Каждый следующий этап — только после проверки, как система держит нагрузку в вечерний час пик. Повторюсь: не факт, что это вообще выйдет на устойчивую монетизацию даже после расширения аудитории — и я предпочитаю писать об этом сейчас, а не постфактум, когда результат уже известен.

Что дальше?

А дальше есть куча идей, которые требуют маломальской обратной связи от тестирующих — нужен ли голосовой ввод, стоит ли генерировать картинки под тематику или же это будет отвлекать от идеи засыпания и больше включать интерес ребенка.

Также и технические долги — неуместность деплоя при пуше в main ветку, отсутствие rolling updates и так далее.

Все это пока что оставлено за бортом умышленно, но есть один вопрос, на который у меня самого пока нет уверенного ответа: стоило ли на MVP‑стадии держать Postgres в Docker на той же VPS ^[1], что и сам бот, или лучше было сразу взять managed‑БД, даже с переплатой, ради меньшего количества точек отказа при первом же росте нагрузки?

Для тех, кто поднимал похожие pet‑проекты с прицелом на реальных пользователей — интересно, как решали этот вопрос вы.