Funfact, маркетинг Red Bull разбирают в университетах как лучшую практику. Но фундаментальную вещь оттуда копировать как раз не стоит. Когда основатель Дитрих Матешиц запускал напиток в Европе, категории энергетиков там еще не существовало. Он сделал все как по учебнику - нанял агентство и протестировал продукт на людях. Им не понравился ни вкус, ни банка, ни логотип. Агентство назвало результаты катастрофой. А Матешиц тогда сказал «Под Ред Булл пока нет рынка, но мы его создадим». И создал… одну из самых быстрорастущих категорий напитков в мире. Красивая история. Но это ошибка выжившего. Тех, кто создавал продукт под несуществующий рынок и закрылся, в институтах не изучают. О том, что продукт надо строить от боли клиента, я узнал поздно. К тому моменту у нас уже получился проект по дистанционному обучению в США. Ставку на него мы делали еще за несколько лет до ковида. Ставка сыграла. И эта удача вскормила эго, что это не удача вовсе, а это мы что-то понимаем и можем даже угадывать тренды. В голове «Часто люди не знают чего хотят, пока им этого не покажешь» крутилось Стива Джобса. Мы придумали маркетплейс школ. Собираешь ребенку учебу как конструктор, каждый предмет в той школе, где его преподают лучше, а мы сводим все в один диплом. Родители текущих учеников не заинтересовались презентацией. Ну ничего, они просто пока еще не поняли как это круто. На найм, разработку и продвижение ушло 42 миллиона рублей, прежде чем мы поняли, что родителям не нужен широкий выбор. Им нужна одна надежная школа и уверенность, что ребенок получит диплом. В целом это можно было проверить через MVP за полтора-два месяца и в 40 раз дешевле. Недавно ко мне подошел молодой стартапер, сказал что они внедряют ИИ в процессы и начал питчить: «А вы знаете, сколько времени люди тратят на трекинг задач? Согласно исследованию…». Я его прервал: — Сколько у тебя платящих клиентов? — Пока нет. — А другие гипотезы есть? — Есть, для ресторанов. В двух уже пилот собираем. — Вот туда и копай. Если тебе нужно убеждать клиента, что у него что-то болит, то боли там нет.

Улучшения наоборот Готовим с командой внедрение системы для проведения A/B тестов. Точнее MVP системы, потому что решили сделать сами, а не использовать готовое решение — с ним слишком много зависимостей и согласований, а наши потребности пока ограничиваются простыми экспериментами на веб интерфейсе. Добрался до конца спеки и задумался: какой эксперимент можно будет провести первым, чтобы проверить насколько правильно работает сбор событий по группам? Понятно, что самым первым нужно провести A/A тест, проверить распределение по группам и совпадение метрик. А вот какой тест должен гарантированно изменить целевую метрику? Решил, что это хороший момент попробовать ухудшающий эксперимент. Когда мы для небольшой тестовой группы в A/B тесте специально добавляем сложность в опыт пользователя. Их используют для других целей, когда делать улучшение сложно и долго, а сделать пробное ухудшение легко. Скорость загрузки страницы сайта и её влияние на конверсию хороший пример. Оказалось, что придумать ухудшение в своем продукте даже сложнее, чем его улучшить! Ведь нужно сделать так, чтобы конверсия воронки заметно уменьшилась, но это не стало блокером для всех пользователей из тестовой группы — сравнивать ноль с текущим значением конверсии невозможно. Пришлось посоветоваться с Клодом. Давайте вместе выберем из его предложений гипотезу для ухудшающего эксперимента? Воронка выглядит так: главная страница с описанием продукта и списком популярных товаров ➔ страница товара с его характеристиками и калькулятором кредита ➔ форма заявки на кредит (имя, номера телефона, адрес почты и поле с выбором уровня дохода) ➔ подтверждение номера телефона через OTP ➔ результат предварительной проверки с переходом на установку приложения. Ваши идеи — в комментарии. Или выбирайте несколько наиболее «правильных» вариантов в опросе👇🏻 1. Задержка страницы товара. Если добавить +1,5-2 с к загрузке, то конверсия «товар → заявка» упадёт, потому что часть пользователей уйдёт, не дождавшись. 2. Пустой калькулятор. Если убрать предзаполненные значения и показывать платёж только после клика «Рассчитать», то конверсия «товар → форма» снизится, потому что цену придётся добывать усилием. 3. Лишнее поле в форме. Если добавить пятое поле (например, город или дату рождения), то конверсия «форма → OTP» упадёт, потому что каждое поле добавляет трение и тревогу от запроса данных. 4. Поздняя валидация. Если убрать маску телефона и показывать ошибки только после «Отправить», то доля завершивших форму снизится, потому что пользователи чаще ошибаются и бросают её. 5. Неудобный OTP. Если убрать автоподстановку кода и увеличить кулдаун повторной отправки с 30 до 60-90 с, то конверсия «OTP → результат» упадёт, потому что ручной ввод и ожидание провоцируют уход. 6. Лишний шаг перед установкой. Если после результата добавить экран с кнопкой «Продолжить», то конверсия в переход к установке снизится, потому что каждый лишний клик теряет часть пользователей. Посты по теме A/B тестирования: 📌 Уровень культуры экспериментов в компании. Как измерить и улучшать 📌 A/B тестирование для начинающих. Ответы на стыдные вопросы 📌 Зачем нужны ухудшающие эксперименты. Хорошая статья от GoPractice #productquestion

я делал простую игру для яндекс игр, могу накидать, что использовал 🤔 blender.org/lab/mcp-server/ - может в пиксельном варианте и не нужно, но 😡 unity.com/ru/blog/unity-ai-mcp-how-to-get-started - мастхев 😘 pen.dev - отрисовка интерфейса, концептов; подозреваю, что можно даже графику рисовать, но не пробовал; рекомендую просить агента работать через CLI, а не MCP 😙 huggingface.co/ACE-Step/acestep-v15-xl-turbo - локальная нейронка (заявлено 24гб врам, но мне кажется я делал на 16) для написания простеньких саундтреков 😆 github.com/gamedev-skills/awesome-gamedev-agent-skills - бесплатный набор скиллов для разработки игр: ии нпс, ощущения от игры, ui/ux и тд думаю, что для mvp этого реально более, чем достаточно. также не забывай, что с подпиской на чатжпт он тебе бесплатно нагенерит пиксельную графику (в веб версии). по итогу лимиты тают на глазах на 5х, но и работа наконец-то делается Репост из нашего чатика t.me/ohld_chat/57467

Стивен наш Бланк написал серию постов, где за вычетом кучи повторов объявил, что описанная из схема Customer Development с MVP в центре объявляется мертвой. Краткое содержание таково: раньше в его стэнфордском семинаре студентам отводилось на разработку MVP 10 недель. По замыслу наличие продукта уже само по себе составляло ценность и moat (защитный барьер от конкурентов). А в этом году все пришли к началу с готовыми продуктами и синтетическими ИИ-кастомеринтервью. Дальше весь семестр возились-возились, да ничего и не продали. https://steveblank.com/2026/09/30/lean-launchpad-the-next-generation/ Бланк думал-думал и придумал, что теперь в онтологию вводится новый элемент "дизайн-партнер", который должен помочь начинающему стартапу чем может, а по списку по сути всем.

Design Partner: A co-developer who first provides feedback, data, workflow access, and real-world testing in exchange for early access, preferential terms, or influence over the product. However, the real metric for success will be when the Design Partner is using the product and getting value out of it. (Design partners can be end-users in companies, warfighters, etc. who can buy or influence a sale.)

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

Weeks 6 – 8 The Search For a Design Partner TBD

И вот это вопрос на миллион долларов посевных инвестиций. Интерес стартапа в "дизайн-партнере" понятен. А в чем интерес "дизайн-партнера"? Что может ему дать стартап, если у "дизайн-партнера" есть все те же инструменты и плюс ресурсы? В случае с потребительским продуктом еще куда ни шло: можно продать аудиторию, бренд (если их сперва создать, а это мегабюджет к наши дни). А с энтерпрайзом даже взрослый продукт налетает на, как я вчера писал "Мы лучше самописку запустим". Похоже, что Стив Бланк и сам ответа не знает. Но MVP похоронил быстро.

Продакт может покинуть тело на время, главное позволить ему сделать это осознанно Я фигачу всегда на чуйке и интуиции. В фреймворках это называется экспертность и вера в результат, зачастую имеет немалый вес, особенно во всяких битуби-энтерпрайзах. И эта штука часто реально работает, если продакт не долбоеб. В одной компании был чел, который на серьёзных щас предлагал сделать кружочки в сториз квадратными, обоснование какое-то даже принёс. Надеюсь он меня не читает. Я пилю продукт, и впервые делаю всё наоборот. Раньше было по уму: родилась идея, прикинул палец к носу, собрал на коленке концепт, пошёл продавать, пока создаёшь. А сейчас вот не знаю какая муха меня покусала. Решил сделать всё хрестоматийно неверно: сначала почти целиком собрать продукт, вложиться в него временем, деньгами и вниманием к деталям, и только потом показать вам и узнать, нужен ли он вообще. Конечно, иногда накрывает тотальной неопределённостью, но держусь. Но главная странность ситуации в том, что мне пока вообще не хочется идти и проверять, купите вы это или нет. Обычно я именно так и делаю: максимально быстро выясняю, есть ли спрос, чтобы не тратить жизнь на Неуловимого Джо. А тут впервые захотелось сначала сделать штуку такой, какой я сам хочу её видеть. Вот прям чуть ли не для себя в первую очередь. Не MVP, не проверить гипотезу, не "достаточно хорошо для запуска", а прям нормально так сделать на совесть. Думаю, причина в том, что впервые делаю продукт не вокруг хардового навыка, который уже освоил и могу упаковать, а наоборот — вокруг вопроса, на который у меня самого пока нет нормального ответа: что вообще делать дальше, когда старый сетап жизни перестал работать, а новый ещё не собран. Этот вопрос в последние пару лет занимает меня всё больше, и, судя по разговорам вокруг, не только меня. Возможно (да точно!), это очень тупой продуктовый подход, через несколько дней узнаем. У меня уже на 70% всё готово, а вы даже не знаете, что это. А штука прикольная, я б купил. Нащупываю здесь хоть какую-то определённость. Поэтому давайте сердечки, если становится интересно!

Разбор проектов подписчиков В одном из видео на YouTube говорил о том, что мы с Николаем Андрюхиным решили сделать бесплатные разборы проектов подписчиков. - Я смотрю на техническую часть, Николай - на продуктовую: нужен ли рынку такой продукт и с чего начинать MVP. Заявки уже закрыты, сегодня будем разбирать присланные проекты. Так что ждите результаты: узнаете какие проекты выбрали и какие рекомендации дали. В телеграмме про это ещё не рассказывал — теперь вы тоже в курсе. Следите за каналом, чтобы не пропустить разборы 👀 Будет полезно послушать как опытным программистам, так и новичкам с желанием создавать свои проекты. #личное · yt · tg · ig

И я туда же Про приложение. Судя по всему, вам интересно, так что продолжу. Сейчас я на этапе проектирования MVP. Вчера я думала, что уже закрыла эту задачу, но сегодня посмотрела на результат свежим взглядом и поняла, что Telegram-бот, на который я ставила, не позволит нормально реализовать нужные пользовательские сценарии. Потому придётся вайбкодить по-взрослому 👻 Я продакт, а не разработчик. В целом понимаю, как устроены разные IT-продукты, но ревью кода сама, конечно, не сделаю. А нейронка может наделать дел. Знаю, что у меня здесь есть программисты, инженеры и люди в теме вайбкодинга, так что дайте пару советов: Как non-tech фаундеру подойти к разработке MVP с помощью ИИ так, чтобы не собрать на старте архитектурного Франкенштейна, который начнет разваливаться при добавлении новых фич? Что вы бы обязательно заложили в процесс разработки с самого начала?

🎾 как за час навайбкодил прототип > протестил > сменил направление в последний месяц дико влюбился в падел, играю постоянно, и для меня это стало способом не выгорать ну и, как это бывает, в какой-то момент начал смотреть на это уже как продакт стал валидировать гипотезу, что у людей есть частая боль — быстро найти 4-го игрока, когда кто-то в последний момент сливается с игры, из инсайтов - множественные сообщения в чатиках побрейнштормил с гпт, выделил сегменты, подумал про риски, потом пошел в клод и буквально за час навайбкодил простой прототип на джанго с базой данных и вот в процессе понял самое интересное: история, скорее всего, не про b2c в лоб логичнее идти через b2b-модель и делать продукт в первую очередь для клубов, а b2c использовать как канал лидогенерации и тебе не нужно рисовать прототипы в фигме, не нужно сливать сотни тысяч на мвп, чтобы быстро протестировать гипотезу навайбкодил пре-мвп > продолжил в том же направлении или же сменил вектор

Вот пример - пришла отбивка, что модуль готов, можно идти заниматься своими делами

🚀 Lock-Screen Preparation Complete

✅ Новый скилл: /founder-lock-screen (поддерживает профили default-evolution и mvp) создан.

✅ Blueprint: Подробный архитектурный план implementation_plan_mvp_lockscreen.md сохранен. Он описывает как будут развернуты Cloudflare Workers, Zaraz, и D1 без затрагивания GKE монолита.

✅ OSINT Research: Фоновый сбор best-practices 2026 года для Cloudflare Workers и Zaraz запущен через Model Council.

Уводите компьютер в Lock-Screen режим! Я начну выполнять шаги из Blueprint'а и раз в 5 минут буду слать heartbeat обновления.

Новое применение Claude Подождите! Не проматывайте на следующий канал. В этом посте не будет ни слова про вайб кодинг, который уже всем порядком надоел 😁 Я хочу вам рассказать про новый подход к разработке внутренних систем для оффлайн процессов. Кто когда-нибудь сталкивался с задачей создания системы, которой ежедневно будут пользоваться десятки людей с разными ролями, в разных локациях, с разным контекстом, тот знает насколько сложно продумать все сценарии и ограничить MVP теми функциям, без которых не обойтись. Именно такая задача стояла перед моей командой — система управления стоком мотоциклов для сети из десятков магазинов дилеров-партнеров, которая позволит оцифровать путь от добавления мотоцикла в продажу до его выдачи покупателю. Стадия развития продукта такая, что никакой автоматизации и синхронизации стоков с партнерами нет. У многих из них нет вообще никакой системы для управления своими стоками. Вместо того, чтобы проектировать сложную систему ролей и прав доступа, мы решили сделать 3 ключевых роли, переключиться на интерфейс которых может любой авторизованный пользователь системы. Грубо говоря это тот, кто управляет стоком всех магазинов, тот кто отвечает за актуальность стока определенного магазина или сети магазинов и тот, кто находится в магазине и отвечает за выдачу товара клиенту. В MVP заложили те действия, которые, как мы думаем, должен делать каждый из них. И главное. На каждое действие в системе добавили логи: какой пользователь, что сделал, с каким юнитом, когда и под какой ролью. И доступ админа, который может в удобном интерфейсе отфильтровать логи по всем параметрам и выгрузить их в CSV. Дальше начинается самое интересное, то что теперь доступно любому с подпиской на Claude Cowork. Нахожу в логах какую-то аномалию, например, продавец удалил юнит из системы вместо того, чтобы отметить его как выданный клиенту. Или менеджер стока удалил юнит и через минуту создал такой же с небольшими отличиями. Прошу Claude сделать анализ всех таких кейсов и получаю идеи для доработок — добавить обязательный выбор причины удаления и предупредить, что при продаже нужно использовать другую функцию. И добавить возможность редактировать определенные параметры у юнитов в доступном стоке для нужной роли. Наверное, к этим выводам мы бы пришли сами. После долгих разговоров с операционной командой, наблюдений за их работой и анализа метрик. Но с Claude это стало возможным после двух недель с момента внедрения системы, когда накопилось достаточно логов для анализа. Бонусом стало добавление интерфейса для анализа логов по юниту, который менеджеры операционной команды используют для «расследования» ошибок своих подчиненных и точеного проведения воспитательной работы 😁 Единственный минус — в этом месяце я дважды достиг лимита токенов, что стоило компании $400. Но, уверен, что польза от таких расходов инвестиций будет намного выше. Ведь каждое улучшение системы, сделанное по наводке AI, улучшает эффективность всего продукта и напрямую влияет на бизнес метрики! #lifehacks #aifuture #claude #salmon

Если лошадь сдохла, слезай У двух совершенно разных людей не прет совершенно разный онлайн бизнес. Продукт хороший. Клиенты довольны. Но клиенты эти штучны, а если начинать их активно привлекать – экономика и близко не сходится, стоимость рекламы радикально не укладывается в маржу. В итоге без всякой отдачи расходуются время, деньги, силы. Один ищет инвестиции, другой спрашивает советов по Growth хакам. У прямых конкурентов-то получилось, они вроде зарабатывают, мы сейчас тот же фокус повторим, тоже рывок сделаем. Мне кажется, обоим следует закрыться и заняться чем-то другим. Бизнес – гипотеза того, что эта команда в этом месте с этими ресурсами может дать результат. Они же проверили эту гипотезу – и результат отрицательный. Нет, не может. Возможно, не хватает компетенции. Конкуренты что-то делают чуть лучше, и это отличает рост от стагнации. Возможно, дело просто в том, что они запустились раньше. Возможно, отличий вообще нет, и у тех тоже дела плохо идут. Но главное – какая в целом разница почему? Не идет. Может с какой-то вероятностью пойти потом, но в новом проекте попрет с вероятностью никак не меньше. Если удалось зацепиться – за управляемый рост, за сходимость экономики, за что-то ещё измеримое – тут мой совет сразу переворачивается. Но пока мы на стадии несработавшего MVP – что ж за него держаться-то. Не все стартапы успешны. #простомысли

Сквозь тернии к ценности Недавно наткнулся на интересную мысль — на раннем этапе продукта полезно оставлять препятствия на пути пользователя к ценности. Звучит контр интуитивно, ведь мы всегда стараемся донести ценность быстрее и до большего числа новых пользователей. А новых на этапе старта — большинство. Но если подумать об этом с другой стороны, то главная задача нового продукта найти свой product market fit. То есть найти сегмент пользователей с проблемой, которую он хорошо решает. И если эти пользователи готовы проходить через препятствия — это хорошо. Такое поведение сигнализирует, что вы попали в их ожидания. Увидеть его можно через аналитику пользовательского поведения и точечных интервью с пользователями, которые совершили ожидаемые вами действия в продукте. На этапе масштабирования уже можно поработать над устранением препятствий. Убрать лишние шаги, оптимизировать процессы по времени, настроить регулярный сбор обратной связи и улучшений на её основе. Главное, чтобы это не стало оправданием запуска продуктов с нелогичным интерфейсом и плохим онбордингом, которые плохо передают ценность вашего продукта. Ну и не затягивать с оптимизацией когда стало понятно, что пользователи готовы решать свою проблему с вашим неудобным продуктом. Здесь на помощь приходят наши любимые инструменты: анализ отзывов, NPS и CSAT опросы, юзабилити исследования и оптимизация воронок. Попробуйте вспомнить какие препятствия вы оставляли в продукте и было ли это оправдано с учетом такого подхода. #mvp #productmarketfit #research

🧑‍💻 3 проблемы, которые вредят вашему стартапу. А вайб-кодинг их лишь усугубляет Сейчас SaaS-решения все чаще создают с помощью нейросетей, и я понимаю почему. Ведь так можно за пару дней запилить MVP и сразу начинать продажи, допиливая продукт по дороге. Но не все так радужно. Я прочитал пост, автор которого уверен: вайб-кодинг не помогает бизнесу. Перевел текст и принес вам - предлагаю обсудить. Вот его мнение 👇 Я разрабатываю SaaS-приложения для разных клиентов, и с появлением вайб-кодинга стал замечать одну и ту же картину. Фаундер создает в нейросети приложение, радуется, как оно классно работает, а потом запускает его и… продукт никто не покупает. Человек думает: “Наверное, не хватает функций” и добавляет темную тему, панель управления, интеграцию. Людям все еще неинтересно, а предприниматель продолжает считать, что с продуктом что-то не так. ✋ На самом деле, проблема не в продукте. Он вообще никогда не был единственной точкой притяжения клиентов. Просто с появлением вайб-кодинга это стало в 100 раз очевиднее - ведь создать MVP или добавить в него функции теперь можно самому. А основатели так увлеклись ИИ-разработкой, что перестали замечать вещи, которые реально вредят бизнесу. Вот что они делают. 1️⃣ Пытаются продавать всем. К примеру, создают продукт, который помогает бизнесу автоматизировать работу. Но не уточняют, какому именно бизнесу - в итоге теряются среди таких же сервисов. Чтобы люди вас заметили, нужно определить: кому именно продаете. Я делал один и тот же продукт дважды: для широкой аудитории и для конкретной группы людей. Так вот, версия для узкой ЦА продалась в 22 раза лучше. 2️⃣ Не предлагают ничего уникального. Основатели часто создают продукт, который хотят сами, а не тот, что нужен аудитории. В итоге получается сервис, который выглядит, как 40 других и ничем не цепляет. Ну а покупатели в этом единообразии просто выбирают самый дешевый вариант. Чтобы люди захотели именно ваш продукт, узнайте, какую проблему они хотят решить. А потом создайте понятный и простой в использовании сервис. 3️⃣ Не составляют план по заработку. Стартапы получают доход с текущих клиентов и радуются выручке, но не учитывают, например, расходы на рекламу. И работают себе в убыток. А когда денег на продвижение не хватает - решают, что новые клиенты сразу придут, как только они добавят пару функций. Но так это не работает. Какая из этих трех ошибок кажется вам самой опасной? Заходите в комментарии - обсудим. 👉🏼 Подписывайтесь на «Телеграмму...» в Максе: max.ru/yumaks #СОВЕТЫ #СТАРТАП #ИИ

Валидация — это мираж «Как проверить, сработает ли фича?» «Как понять, стоит ли разрабатывать продукт заранее?» «Как узнать, будут ли люди покупать это?» «Как подтвердить соответствие продукта рынку?» «Как проверить UI/UX/механику...» Никак. Никак. Никак. Никак. Никак. Нельзя проверить Идею. Нельзя валидировать догадку. Нельзя валидировать абстракцию. Нельзя валидировать эскиз, макет и MVP. Нельзя проверить то, чего ещё не существует. Наш мозг ищет уверенности заранее, ему сложно вернуться к работе в ином режиме. Но отсчёт времени начинается не тогда, когда вы приступаете к работе или когда готов какой-то фрагмент Целого.

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

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

Если вы создаёте продукты, вы должны понимать, куда движетесь, не спрашивая у других дорогу на пути.

Есть лишь один способ максимально приблизиться к уверенности — создать реальный продукт/фичу и выкатить их в паблик, чтобы их можно было: попробовать (→) использовать (→) купить. Потому что именно так ВСЁ работает в реальности. Именно так работает реальность. Реальное использование реального продукта в реальных условиях и в ходе реальной работы — вот тот единственный способ что-либо проверять. Поэтому самый работающий в реальности способ всё выяснить — поверить в идею, воплотить её в жизнь и выпустить её в мир. Вы делаете все, что в ваших силах: 1. вы Это Предчувствуете; 2. вы Это Видите 3. вы формируете Намерение 4. вы двигаетесь сквозь Это вместе Продукт — это совокупность взаимосвязанных элементов: они зависят друг от друга, перетекают один в другой, интегрируются между собой. Нельзя взять кусок продукта, спросить людей, нравится ли он им, и сделать вывод, что им понравится и остальная часть, когда она будет готова. Так вы узнаете лишь то, нравится ли им конкретно этот кусок, который вы им дали.

Все экстраполяции/валидации и верификации – додумки и обман нашего мозга.

Поэтому не принимай впечатление от отдельной части продукта за Истину. Давая человеку кусок чего-то неоднородного, ты вынуждаешь его угадывать вместе с тобой и на этом нельзя строить Намерение, Видение и Движение. Хочешь усомниться в себе/фиче/продукта/ и в конечном результате — устрой тест/опрос/коридорное тестирование или просто спроси кого-нибудь ещё, что он думает о твоей идее/фиче/продукте. Созданная таким образом "неопределённость" –  единственное, что сработает безотказно в этой "реальности". И всё будет как на картинке выше.

Всем Капуки! ❤️ Сыну нравится нейрослоп мультики про котика 😻кефира. Они безобидные, добрые, сценарии хорошие и анимация котенка тоже годная. На сколько там фронтмэн девушка живая и сама снимает или там уже прям оцифровали ее аватар - хз. Но делаю MVP контент-завода для сына кастомного, с кастомными персонажами из его игрушек / рисунков и друзей со двора. Архитектура/blueprint готовы. Пробую в spare time через фрактальный MAS реализовать и тестить. PDF сказки / рисунки с игрушками и фотками уже есть. 2D Игры с машинками / людьми которые через OpenAI говорят разные фразы/диалогы - есть. Озвучка животных и рандомная генерация карты в стиле GTA1-2 есть. Физика машинки и столкновений с рандомными эффектами звуковики и жалобы людей - есть. Пора переходить в КАПУКИ like контент и адаптивные/эволюционные игры детские под настроение / запрос и взаимодействие через мигрофон. Детский контент самый нетребовательный. + отдельно можно по лучшим практикам обучения домашнего - генерить книги / упражнения / видео / игры / приложения и тд и тп. Отправил думать

Я попросил у OpenAI Codex: а собери мне скелет AI Native проекта под мою задачу (5 минут объяснения про платформу для выгрузки видео про AI Coding, практических примеров и обсуждений на ~200 человек). Задачку я запустил из Control Center в Agentic Loop режиме (goal mode) и сказал, какие блоки из каких уже подключенных к центру проектов брать. В этот раз получилось сильно симпатичнее, чем обычно. Почти нет желания доделывать. Пару странных решений Codex втихую протащил, но никаких самопальных тестов в этот раз, что уже прогресс. Дальше - зачистить напильником шероховатости (чтобы задать тон будущему коду) и завести BDD спеки (SDD без вайб-зависимости). Очень круто видеть, как с каждым месяцем путь от идеи/эксперимента до первых MVP все больше сокращается! Ваш, @llm_under_hood 🤗

Покажи за 30 секунд — Расскажу про проект, — начал продакт — Лучше покажи В 2008 году стартапер объяснял инвесторам про свой продукт: «Облако, которое использует кроссплатформенный механизм для синхронизации файлов». Они покивали — но денег не дали. Со злости Дрю Хьюстон записал трехминутный ролик: вот файл на одном компьютере — а вот он появился на втором. Никакой инфографики, объяснений, бюджета — просто видео, как живой человек кладет файл в папку. Залил видюшку в сообщество Digg и получил 75 000 регистраций за сутки. С этого начался Dropbox. Семнадцать лет прошло, а мы все пишем лендинги, ищем хитрые ходы, продающие офферы. Но принцип прост — покажи. За 30 секунд станет понятно, чего стоит продукт. Не смотрят — не понимаешь рынка. Не понимают — не знаешь аудиторию. Нет людей — вообще влажные фантазии. 30-секундное видео — это и есть MVP. Попробуй сделать его. «Не все можно показать, — скажет читатель. — Есть сложные В2В-решения; ценность, раскрывающаяся на 3-й месяц; кастомизация...». Это — так. Но тогда возникает вопрос: если не можешь привлечь и удержать 30-секунд внимание клиента, как собираешься повторить этот трюк с его деньгами?!