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

Я CRM-маркетолог. Я не умею программировать в классическом смысле: не пишу код с нуля, не проектирую архитектуру как разработчик и до недавнего времени слова вроде API, callback, Docker и Supabase вызывали у меня жжение ниже поясницы и желание закрыть ноутбук.

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

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

Внутри: Telegram-бот, BotHelp, n8n, генерация текста, генерация изображений, вебхуки, PDF, оплаты, костыли, ночные правки, возвраты, первые продажи и примерно 5000 созданных сказок.

Это не история про “как за вечер собрать стартап на нейросетях”.Это история про то, как человек без навыка программирования может довести идею до работающего продукта — если готов терпеть боль, тестировать, переделывать и не ждать, что ИИ сделает всё сам.

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

Задача звучала просто: сделать музыкальное лото.

На тот момент мой опыт позволял собирать простые воронки в BotHelp: “привет”, “оплати”, “получи доступ”. Поэтому я подумал, что задача будет лёгкой.

Оказалось, что музыкальное лото должно быть переигрываемым: 52 трека должны выпадать случайно и без повторений. Сейчас я уже понимаю, что это нормальная задача на логику. Тогда я решал её в конструкторе через IF-блоки, теги и случайный выбор.

Получилось около 440 блоков. Бот иногда тормозил, рандом вёл себя странно, ближе к концу партии свободных вариантов становилось всё меньше — но продукт работал. Заказчик принял работу.

Тогда я впервые посмотрел в сторону n8n, но быстро закрыл вкладку. Слишком сложно. Непонятные вебхуки, какие-то VPS, Docker, сценарии, ноды. Я решил, что это не моё.

Спойлер: потом всё равно пришлось туда вернуться.

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

На бумаге всё выглядело просто: пользователь отправляет фотографию, нейросеть делает видео, бот возвращает результат.

В реальности я впервые столкнулся с API, токенами, headers, body, task_id и тем, что генерация не происходит мгновенно. Сервис не отдавал готовое видео сразу. Он создавал задачу, а результат нужно было либо ждать через callback, либо периодически проверять статус.

В BotHelp нормально принять callback было сложно, поэтому я сделал грубую схему:

запросили генерацию → подождали 30 секунд → проверили статус → если готово, отправили видео → если не готово, подождали ещё → если ошибка, отправили уведомление мне.

Это было не идеально, но работало.

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

Я не стал разработчиком, но перестал воспринимать разработку как магию.

Я продолжал смотреть на пользователей, промпты, конверсии, конкурентов и в какой-то момент поймал себя на мысли: “Я могу сделать что-то своё”.

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

Идея пришла из личной жизни. У меня есть ребёнок, и я видел, как детям бывает непросто втягиваться в чтение. Так родилась идея персональных сказок: ребёнок становится главным героем истории, видит себя на иллюстрациях и получает не просто текст, а персональный подарок.

Я описал идею ИИ. Он сказал, что реализовать можно. Желательно — за пару месяцев и с командой разработчиков.

Фрилансер, к которому я обратился для проверки реальности, оценил работу примерно в три месяца и 200 тысяч рублей.

200 тысяч на тест гипотезы у меня не было. Поэтому я спросил ИИ прямо: можем ли мы сделать это вдвоём — я и он?

Ответ был: да, если использовать low-code и n8n. Так я снова открыл n8n (теперь это первое, чтоя открываю утром и последнее что проверяю вечером)

На старте у меня не было нормальной архитектуры. Сейчас я понимаю, как это должно было быть устроено. Тогда — нет.

Первая версия продукта состояла из одного большого workflow в n8n.

Пользователь проходил воронку в Telegram-боте, оплачивал заказ, отправлял данные ребёнка, а дальше всё улетало в n8n:

сгенерировать текст сказки → сгенерировать промпты для иллюстраций → отправить запросы в генератор изображений → подождать результаты → собрать HTML → превратить его в PDF → отправить пользователю.

Звучит аккуратно. В реальности это был огромный хрупкий механизм.

Внутри были Telegram-ноды, уведомления мне в личку, сгенерированные ИИ куски JavaScript, ручные правки HTML, Google Sheets вместо базы данных и Gotenberg для генерации PDF.

Я не писал код сам. Я делал примерно так:

“Вот входящие данные. Вот ошибка. Вот что должно получиться. Дай готовый код для этой ноды и объясни, куда его вставить”.

ИИ писал. Я копировал. Иногда работало.

Когда первая версия хоть как-то заработала, я решил, что пора запускаться.

Я закупил рекламу примерно на 10 тысяч рублей. Получил около 20 подписчиков и 3 заказа по 490 рублей.

С точки зрения юнит-экономики — провал.С точки зрения продукта — первый важный сигнал. Так выглядели первые сказки.

Людям идея нравилась. Пользователи видели ценность в персональной сказке. Это был не просто “AI ради AI”, а понятный подарок для ребёнка.

Я добавил выбор темы сказки, начал писать блогерам, получил несколько публикаций, ещё подписчиков и ещё заказы.

Продукт всё ещё был сырым, но стало понятно: спрос есть.
(спасибо всем, кто писал отзывы, мне это очень важно)

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

Мы переделали воронку в Telegram-боте, обновили дизайн PDF и запустили рекламу.

К концу декабря количество подписчиков превысило 1000, заказов стало около 200, оборот приблизился к 70 тысячам рублей.

Это была хорошая новость.

Так выглядели

Плохая новость: продукт регулярно ломался.

Каждый второй заказ мог сыпаться из-за ошибок генерации. Картинка не сгенерировалась, нейросеть вернула ошибку, task_id потерялся, PDF собрался с пустой страницей — и пользователь получил не сказку, а повод написать в поддержку.

Поддержкой был я.

Я вручную открывал историю workflow, доставал HTML, находил упавшие изображения, перегенерировал их, менял ссылки в Visual Studio Code, снова собирал PDF и отправлял пользователю исправленную версию.

Возвраты держались на уровне 25–30%.

Сейчас я понимаю, что это была проблема не “плохой нейросети”, а плохой архитектуры. Система не проверяла, все ли изображения действительно готовы. Не было нормальных ретраев, статусов, контроля качества и админки.

Тогда я просто тушил пожары.

К концу декабря у меня был работающий AI-продукт. Он принимал деньги, создавал персональные сказки и нравился маленькой части пользователей. Но внутри это был набор костылей.

Главная ошибка первой версии — я рассчитывал на 100% успешных генераций. Так не бывает. Оказалось что как бы не обещали 99% аптайм и классное качество генераций изображений -- частенько генерации сбоят(

Любая генерация может упасть. Любой внешний сервис может вернуть ошибку. Любая картинка может не пройти фильтр.

Я этого не знал. Поэтому продукт работал, но требовал постоянного ручного вмешательства. Тем не менее именно эта версия доказала главное: люди готовы платить за персональные сказки.

А значит, продукт нужно было не бросать, а переделывать.

В версии 0.2 я начал исправлять главную боль: визуальную консистентность (постоянство) главного персонажа.

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

Для пользователя это критично. Если он заказал сказку про своего ребёнка, он хочет видеть своего ребёнка, а не “примерно похожего персонажа”.

В новой версии после генерации текста отдельный ИИ-блок создавал референсы персонажа. Появился спутник героя — sidekick, проводник по сказке. Темы стали разнообразнее: волшебный лес, космос, роботы, море, динозавры, случайная тема и своя тема.

Для детей младше трёх лет текст стал проще: больше повторений, звукоподражаний, коротких фраз. Продукт стал лучше. Продажи в январе выросли. Пользователи начали возвращаться и заказывать повторно.

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

Сегодня мой бот работает 24/7, появилась админка, автоматические системы которые отлавливают упавшие генерации и перезапускают их, стало меньше ручной возьни и больше времени. Я очень сильно прокачал иллюстрации, настолько, что пришлось приобрести файловое хранилище так как ПДФ файлы в 60-70МБ не помещаются в мессенджер. Сегодня в сказку можно добавить второго персонажа, указать мораль, которой будет пронизана сказка.

Что осталось -- из важного, мне нравятся сказки которые я создаю. И ещё остался старый лого, я могу навайбить с чатгпт красивый новый лого, но текущий мил моей душе. Все желающие -- велком

Главный вывод: ИИ не сделал меня программистом. Я не стал человеком, который может сесть и написать нормальный backend с нуля. Я не стал специалистом по архитектуре, безопасности, базам данных и продакшен-разработке.Но ИИ дал мне возможность пройти путь от идеи до работающего продукта без команды и большого бюджета.

Раньше между “у меня есть идея” и “у меня есть продукт” стояла высокая стена: разработчики, бюджеты, ТЗ, месяцы ожидания, риск потратить деньги и получить не то.Теперь эта стена стала ниже.

Не исчезла, но стала ниже. ИИ не отменяет разработчиков. Человек, который пишет онлайн-банк, не будет заменён CRM-маркетологом с n8n и ChatGPT. Большие сложные системы всё ещё требуют инженерного мышления, опыта и ответственности.

Но для MVP, внутренних инструментов, ботов, автоматизаций, нишевых продуктов и проверки гипотез возможности стали совсем другими.

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

Первое — я не пытался сразу сделать “идеальный стартап”.Я сделал кривой MVP, получил первые деньги и начал чинить то, что болело.

Второе — я использовал инструменты, которые уже понимал.BotHelp был не идеален, но там были оплаты, рассылки и понятная мне логика. Поэтому я не стал сразу переносить всё в n8n, хотя технически это было бы правильнее.

Третье — я относился к ИИ как к техлиду для бедных, а не как к волшебной кнопке.Он писал код, объяснял ошибки, предлагал схемы, помогал с API, но решения всё равно приходилось принимать мне.

Четвёртое — я постоянно смотрел на пользователей.Если бы первые клиенты сказали “не нужно”, я бы остановился. Но они говорили другое: идея классная, подарок эмоциональный, ребёнку нравится — только сделайте, пожалуйста, чтобы ничего не ломалось.