Всем привет. Я CRM-маркетолог, который не умел (и всё ещё не умеет) программировать, но всё равно собрал коммерческий продукт: сервис, который создаёт индивидуальные иллюстрированные сказки для детей.

Внутри — n8n, BotHelp, чатгпт (тут и далее - имя нарицательное, к OpenAI не имеющее отношение), генерация изображений, вебхуки, long polling, callback, костыли, боль, первые продажи, возвраты, ночные правки и примерно 5000 сгенерированных сказок за спиной.

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

Спойлер: статья про взаимоотношения с ИИ, но при её написании ИИ не использовался. Читать на свой страх и риск — в конце концов, вы сами виноваты, что платите за интернет.

---

Начало

Летом 2025 года мне написал бывший работодатель — селлер со стажем, который продавал на маркетплейсах хайповые карточные игры собственной разработки.

Логика продукта была простой: человек покупает физическую игру, сканирует QR-код, переходит в Telegram-бота и получает дополнительный цифровой контент для партии.

Запрос тоже казался простым: нужно было сделать музыкальное лото.

Мой бэкграунд CRM-маркетолога на тот момент позволял собирать простые боты в духе «привет, оплати, получи доступ к вебинару». Поэтому я подумал: легкотня. Взял задаток и начал ваять бота в BotHelp (не реклама: альтернативой рассматривался более функциональный Selbot, но его функционал показался мне слишком сложным, а интерфейс — не самым дружелюбным).

В процессе создания бота всплыл нюанс: музыкальное лото должно было быть переигрываемым: в игре было 52 «бочонка-трека», которые должны выпадать в случайном порядке и без повторений. Позже я узнал, что количество возможных порядков выпадения 52 уникальных элементов — это 52!. Что такое факториал, я тоже узнал во время разработки. Не пинайте гуманитария.

У конструктора было ограничение в 550 блоков. Мне хватило 440.

Реализовывать это пришлось при помощи простых блоков IF и одного блока «Случайный выбор». В итоге задача была решена за неделю.

Как ни странно, бот работал. Иногда, правда, тормозил. Рандом, такой рандом: блок «Случайный выбор» мог 15 раз подряд отправить пользователя в выход №1, где if проверял наличие тега и возвращал обратно в блок случайного выбора. Особенно весело становилось ближе к концу игры, когда свободных вариантов оставалось всё меньше.

Но заказчик работу принял и выплатил остаток.

Во время разработки я прочитал пару статей про n8n, посмотрел на всё это и решил: нет, это не моё. Слишком сложно. Что такое n8n отлично расписано тут https://habr.com/ru/companies/amvera/articles/912560/ (кстати, я смотрел в сторону amvera для vps, но интерфейс показался слишком сложным и я выбрал другого провайдера).

Продолжения начала

Осенью 2025 года бывший работодатель, видимо впечатлённый моими познаниями и успехом с музыкальным лото, пришёл с новой задачей: сделать Telegram-бота, который «оживляет фотографию».

«Раз плюнуть», — сказал я, взял задаток и пошёл гуглить, как вообще можно оживить фото.

Оказалось, что всё просто: есть нейросеть Kling, у неё есть API. Оформляешь подписку, отправляешь в header токен, в body — фото и текстовое описание, а на выходе получаешь видео.

Что такое header, JWT token и body, я узнал из документации к API. Спасибо китайским разработчикам: словообразование в вашей документации примерно соответствует моему уровню английского.

Дальше, конечно, выяснилось, что всё снова не так просто. Kling не возвращал готовое видео сразу. Он создавал задачу и отправлял уведомление о результате генерации через callback. Проблема была в том, что в рамках BotHelp этот callback нормально принять было некуда.

Пришлось делать по-простому: «ждать 30 секунд» → «дёрнуть API по task_id» → если статус completed, отдать подписчику видео → если waiting, подождать ещё 30 секунд → если failed, отправить уведомление техподдержке. То есть мне.

Как ни странно, бот работал. Процент ошибок был небольшим, заказчик работу принял и выплатил остаток.

Позже я узнал о такой вещи, как агрегаторы ИИ, и заменил Kling на Grok: он оказался дешевле.

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

Конец начала

В ноябре 2025 года я продолжал поддерживать «оживлятор»: смотрел на аудиторию, количество подписчиков, конверсию, пользовательские запросы, промпты и конкурентов.

И в какой-то момент поймал себя на мысли: «Я могу так же».

Тогда я собрал ещё одного бота — уже своего. Он умел брать фотографию и менять её: переодевать человека, переносить его в другой образ, стиль или сцену. С наработками после «оживлятора» это уже не казалось магией.

Я пришёл к бывшему работодателю с предложением:

— У тебя есть «оживлятор», у меня есть «переодеватор». Ты умеешь в рекламу, я умею в ботов. Запускаем, барыш пополам.

В идею он не поверил и предложил придумать что-то ещё. Думал я недолго. С одной стороны, делать очередную Telegram-обёртку над агрегатором нейросетей было уже не так интересно, да и заполнен этот рынок по самое не хочу. Даже Алиса периодически отправляла уведомлялки, что она умеет быть «оживлятором» и даже, сюрприз-сюрприз, «переодеватором».

Прикинув (как я ошибался), что «обёртки» вымрут, задумался над сервисом, который мог бы давать что-то большее, настоящую ценность. Посоветовавшись с котом и посмотрев на то, как сложно сыну даётся чтение, я купил платный чатгпт и пошёл придумывать свой продукт: генеративные иллюстрированные персональные сказки.

Модель казалась простой: родитель заходит в Telegram-бота, отправляет имя и фото ребёнка, ИИ пишет текст сказки, наработки из «переодеватора» превращают фото в иллюстрации, всё это собирается в понятный для пользователя формат и отправляется готовым файлом в формате PDF. Чатгпт сказал, что идея огонь и что реализовать её можно примерно за два месяца - наняв команду разработчиков. Фрилансер, к которому я обратился для проверки реальности, сказал: три месяца и 200 тысяч рублей.

Я аккуратно спросил у чатгпт, сможем ли мы (я и чатгпт) реализовать мою задумку без команды, ИИ ответил положительно и предложил использовать lowcode платформу типа n8n. 200к на тесты у меня в кармане не завалялись, так что для меня выбор был очевиден.

Начало разработки своего продукта (и так далеко от начала статьи)

Бюджет на разработку я ограничил 20к и был готов бросить всё, когда начал читать что надо VPS, куда устанавливается Docker в котором надо установить n8n (суслик_кричит.пэнэгэ). К счастью, дополнительный гуглинг показал, что можно приобрести VPS с предустановленным n8n.

Тогда, плана и понимания архитектуры проекта у меня не было, в мае 2026 они появились (с учётом, что проект был запущен коммерчески в декабре 2025 – думаю всё было сделано правильно и вовремя).

Итак, сценарии автоматизации в n8n называются workflow, но я буду называть их просто флоу. Первая итерация продукта состояла из одного большого флоу. На вход прилетали данные из вебхука BotHelp (я продолжал использовать BotHelp в основном по двум причинам: там уже была интеграция с платёжными системами, а ещё я понимал ценность дожимных рассылок внутри бота).

Чатгпт уверял, что всё это можно реализовать и в n8n. Он даже пытался описывать архитектуру, но я посмотрел на неё, понял, что пока не готов, и продолжил использовать ставший родным BotHelp.

Первый флоу выглядел так:

Прелестная версия 0.1, да она часто падала, но иногда работала.

Почему так много Телеграм нод

Внимательные хабравчане на скриншоте флоу заметят несколько подозрительных Телеграм нод. Разработчик (я) решил, что они нужны для отправки уведомлений тех. поддержке - мне. Эту практику я использую и сегодня, люблю получать уведомления.

Для генерации иллюстраций я использовал старую NanoBanana. Выбирал просто: по соотношению стоимости и качества. На каждую сцену уходил отдельный промпт.

Пример промпта

Пример одного из промптов выглядел примерно так:

Создай иллюстрацию на основе загруженной фотографии девочки. Сохрани её лицо, черты, возраст и пропорции. Девочка должна быть одета в красивое детское платье принцессы: лёгкое, воздушное, пастельные тона, блёстки, декоративные элементы. Основные персонажи должны занимать верхние 3/4 изображения. Нижняя 1/4 обязательно должна быть фоновой: размытой, затемнённой, без деталей, чтобы туда можно было разместить текст. Используй следующий сюжет как визуальную тему сцены: [сюжет]. Изобрази атмосферу доброй сказки: мягкий свет, тёплые оттенки, мягкие тени, высокая детализация. Иллюстрация должна быть яркой, эмоциональной и выразительной. Формат: детская сказочная иллюстрация, высокий уровень детализации, плавные контуры, аккуратные цвета.

А сюжет для конкретной сцены мог быть, например, таким:

Жила-была маленькая девочка Юля. Она была светловолосая, с голубыми глазками, как два кусочка неба. Однажды Юля гуляла по двору и услышала: «Мяу-мяу…» — тихое, жалобное, будто кто-то звал её на помощь.

Как выглядел тестовый Лев на соседних иллюстрациях

Думаю, специалисты по ИИ графике уже на этом месте, понимающе улыбнулись.

Проблема была заложена в сам подход: каждая иллюстрация генерировалась отдельно, по схеме 1 запрос = 1 сцена = 1 иллюстрация. Формально нейросеть рисовала одного и того же персонажа, но на практике это был «примерно тот же ребёнок»: похожее лицо, похожий возраст, похожее настроение — но в разных сценах могла плавать одежда, слегка меняться черты лица, пропорции. Тогда мне это не казалось критичным. Сейчас я бы назвал это первой большой архитектурной ошибкой.

Дальше начиналась, как мне тогда казалось, «простая» часть: отправить все запросы, подождать две минуты и потом попробовать получить результат по task_id. То есть классический long polling.

В тот момент я бесстрашно рассчитывал на 100% успешных генераций. Три раза ха.

После этого в дело вступала неимоверно сложная для моего понимания и полностью сгенерированная чатомгпт JS Code-нода. Она собирала из текста сказки и ссылок на картинки HTML-файл (вёрстка, конечно, тоже была возложена на плечи чатгпт).

Первые версии PDF я генерировал через внешний онлайн-конвертер. С учётом, что мой бюджет был ограничен, затраты приходилось резать по максимуму, а платить за каждую конвертацию было неприятно. Узнав у чатгпт про альтернативы, я попросил поддержку VPS установить Gotenberg (gottenberg это тоже нечто докерное, которое позволяет генерировать pdf, тыц).

Прогнав пару тестов для себя, я понял «пришло время», и закупил рекламу на остаток бюджета. Реклама прошла на ура, принеся 20 подписчиков и 1 заказ. Заказу я был рад. Юнит-экономике — нет. В итоге я потратил около 10 тысяч рублей и получил три заказа по 490 рублей.

Пользователям сказка понравилась. Я гордился своей идеей, но не продуктом — ещё нет. Собрав обратную связь от пользователей, я добавил функционал выбора темы сказки и начал писать знакомым и не очень блогерам, предлагая им рассказать о моих сказках. Суммарно вышло 3 поста, 2 тысячи просмотров, около 50 подписчиков и ещё 2 заказа.

одно из первых сгенерированных изображений, текст накладывался отдельно.

Я всё также гордился своей идеей и написал бывшему работодателю с тем же предложением: с меня продукт, с тебя подписчики. На этот раз работодателю Диме идея понравилась, он предложил полностью переделать воронку в телеграм боте и дизайн конечного pdf.

Я был против! Поэтому пришлось поменять воронку и написать дизайнеру Димы (привет Оля, люблю тебя, и ненавижу за ночные кошмары – 30 раз менять фонт, отступ в пикселях, толщину). Дима сделал тестовый заказ, сказал «сойдёт для теста» и запустил рекламную кампанию. На дворе середина декабря, к концу месяца количество подписчиков превысило 1000, количество заказанных сказок 200, оборот стремительно приближался к отметке 70.000. Это было из хорошего.

Внимательный читатель заметит, что 200 × 490 рублей — это ближе к 100 тысячам, а автор почему-то пишет про 70. Сейчас расскажу всю правду.

В то время каждый второй заказ сыпался из-за ошибок. Сюрприз: не все генерации бывают удачными. Генератору было всё равно, сгенерировалась картинка или нет. Даже если изображение не генерировалось (привет ошибка 500, internal error, здравствуйте «content generation restrictions»), пользователю всё равно отправлялась PDF-ка с пустыми страницами. Такие заказы я переделывал вручную: выгружал HTML из истории флоу, находил упавшие картинки в личном кабинете агрегатора ИИ-шек, перезапускал их, получал новые ссылки, редактировал HTML в Visual Studio Code, заново генерировал PDF и отправлял покупателю исправленную версию.

Всё это было страшно неудобно для поддержки, то есть для меня. Имеющимся количеством костылей можно было построить бункер. Негативных отзывов было много, а количество возвратов держалось на уровне 25–30%.

Ещё отзывы

у меня есть папка со скриншотами отзывов, когда мне не хватает мотивации для очерёдной переделки флоу - эти отзывы придают мотивации и пополняют ману.

Простите Вероника, сказка которую вы приобрели в декабре, была пиком моих возможностей на тот момент

Почти конец статьи, но всего лишь начало бесконечных итераций апдейта генератора сказок

Это был конец декабря, версия генератора сказок 0.1. У меня за плечами был запущенный IT-продукт — не какой-то там Minecraft, нет! Мой продукт использовал ИИ ))

Напомню, что за всё это время я не написал самостоятельно ни одной строчки кода. Я использовал чатгпт, чатгпт использовал меня, процесс работы выглядел примерно так:

Вот вход в ноду X. Вот экспорт флоу. Вот ошибка. Дай корректный код для ноды.

Как CRM-маркетолог я следовал главному правилу: всё, что попало в CRM, должно сохраниться для будущих поколений. В роли CRM у меня тогда выступал Google Sheets туда я аккуратно складировал все заказы, task_id, промпты и прочие результаты жизнедеятельности генератора сказок.

Статья уже получается длинной, поэтому про версию 0.2 расскажу коротко: что изменилось по сравнению с 0.1, какие костыли стали чуть менее острыми и почему это всё равно не спасло меня от бесконечных итераций.

В версии 0.2, которую я создавал в новогодние выходные, я решил свою основную боль. Теперь после ИИ-генерации текста сказки другая ИИ-нода генерировала два референса: первый — только основного персонажа, второй — персонажа и его спутника. Sidekick — это проводник в сказке, с которым персонажу предстояло встретиться на 2–3-й странице рассказа. В зависимости от указанного возраста ребёнка менялся сюжет и сложность словоформ сказки. В какой-то момент для детей в возрасте до 3 лет упор делался на звукоподражание, например: «поднялся ветер, стало тихо-тихо, начал капать дождик: кап-кап». Появились сюжеты сказки на выбор: «Волшебный лес», «Путешествие в космос», «Город дружелюбных роботов», «Море и приключение», «Динозавры». Плюс ещё два варианта: «Рандом» — мы сами не знаем, что будет, — и «Своя тема».

Основной проблемой оставался long polling: генерация падала с ошибкой на стороне нейросети, и либо падал сам флоу, либо генерировалась PDF-ка, в которой отсутствовали страницы.

Я сделал для себя «админский» флоу. Я всё так же выгружал HTML из истории продакшен-флоу, редактировал ссылки на иллюстрации и «в один клик» загружал HTML в админский флоу, после чего получал PDF-файл себе в личку и пересылал заказчику.

В январе количество продаж удвоилось, что радовало ещё сильнее: пользователи возвращались и заказывали повторно.

Выводы

Как на меня повлияло наличие «умного и доступного» ИИ? Однозначно положительно! Я смог создать «программистский продукт», который из входных данных творил «магию» и возвращал красивую сказку пользователям. Сам сервис как MVP стал коммерчески успешным. Научился ли я чему-либо как кодер?

Однозначно нет, я так и не написал ни строчки кода. Да я читал документацию, да я делал флоу, куда копипастил целые ноды написанные нейросетью (и при этом не имел ни капельки понимания что именно я копирую, инструкции от нейросети были в духе «скопируй на пустое место на канвасе, протяни стрелочку от ноды Webhook в новую ноду, из новой ноды протяни стрелочку до ноды AI Generate Tale Text. Да и сегодня мой самый частый запрос в чатгпт выглядит так «сделай стрингифай, вот контент».

Кажется ли мне, что чатгпт заменит программистов? Нет. По крайней мере, не тех программистов, которые создают большие, сложные и монструозные системы. Человек, который писал онлайн-банк, продолжит писать онлайн-банк. Просто, возможно, с другими инструментами и другой скоростью.

Программист, который годами делал сайты на любимом движке, будет делать такие же сайты, но быстрее. Возможно, это и есть тот самый вайбкодинг.

А CRM-маркетолог, который впервые установил Visual Studio Code, чтобы править ссылки в HTML-файлах, — например, я, — сможет создать что-то самостоятельно. Не сразу. Не с первой итерации. После десятков end-to-end-тестов. Но сможет.

И, по-моему, это прекрасно. Не потому, что теперь «разработчики больше не нужны». А потому, что между идеей и продуктом стало меньше непреодолимой магии. Например, меньше магии в духе «вжух — и 200 тысяч фрилансеру на реализацию».

Стал ли я вайбкодером? Нет. И ещё раз нет)

Мне кажется, что вайбкодинг подразумевает, что человек получает результат легко, красиво и вайбово. Я же потел над каждой версией генератора сказок.

Да, мне пришлось выучить самые базовые нюансы, связанные с API-запросами, PostgreSQL (Supabase, ты прекрасен!) — и понять, что такое идемпотентность. Но программистом я всё равно не стал.

Думаю, для первой статьи на Хабре достаточно. Как говорит мой любимый Булджать: сделайте 100 тысяч лайков, и я выпущу вторую часть (Булджать, где «Пчелиная война 2»?!)

Во второй части я планирую рассказать о периоде февраль–март, версиях генератора сказок 0.3 и 0.4 — они мало отличаются, — и о текущей версии 1.1, которой я уже горжусь и которая уже далеко не MVP. В текущей версии для тех. поддержки (меня) появилась админка, а пользователи получают референс персонажа и мы вместе его правим (знали бы вы как я горжусь персонажем который 100% передал изюминку ребёнка - гетерохромию)

Ещё расскажу, как мне пришлось уйти от long polling к callback, начать использовать Supabase на полную, разобраться со статистикой заказов и дойти до 5000 сгенерированных сказок. Есть что рассказать.

Ах да, ещё у меня настолько выросло качество иллюстраций — а вместе с ним и «вес» итогового PDF: с 6–12 МБ до 50–60 МБ. Правда, это было связано ещё и с тем, что я перешёл на PNG-иллюстрации. В итоге пришлось купить S3-совместимое хранилище и складировать PDF туда. Ну и до кучи — сделать онлайн-просмотрщик сказки, чтобы родители не мучились, пересылая 70-мегабайтный файл в WhatsApp бабушкам и дедушкам.

А ещё, судя по рынку, я, кажется, первый, кому удалось уговорить генератор сказок создавать истории для двух персонажей с 85-90% консистентностью.

Вы легко найдёте 10 отличий

Спасибо за внимание. Ссылок не будет. В роли автора статьи и разработчика (нет!) генератора сказок — CRM-маркетолог. В роли тех. поддержки — CRM-маркетолог. В роли чатгпт — ChatGPT и Gemini 3.1.

Как создать продукт, так и не став программистом