Transcription
Я создал свой микро стартап меньше чем за сорок часов и записал весь процесс разработки от примерно сформулированной идеи до полноценно работающего продукта с готовой монетизацией, развернутого в сети под доменом. В этом видео покажу все этапы работы, стек, технологии и фишки, которые использовал. Расскажу, как создавать системы быстро, какие есть нюансы и потенциальные проблемы. Поделюсь своими фейлами, находками и выводами. В общем, если хотите запилить свой стартап сами, то используйте это видео как гайд. Погнали!
Привет! Меня зовут Олег. Вне YouTube я разработчик, но на этом канале скорее вайб кодер. Здесь я тестирую AI инструменты, автоматизирую всякие штуки, показываю свои небольшие проекты, пытаюсь выяснить, что реально работает, а что нет.
Создать свой микро стартап в соло, на мой взгляд, это всегда хорошая идея. Из затрат только собственное время, а из преимуществ - это работа над интересной идеей, хороший опыт доведения продукта до конца, а также какой-то шанс даже что-то на этом заработать. Однако такие проекты очень часто растягиваются на долгие месяцы, усложняются в сотни раз и крайне редко доживают до релиза. Потому что работа за идею в течение долгих месяцев действительно требует очень большой выдержки и упорства. Это исключительно сложный путь.
Поэтому я предлагаю чуть более простой подход. Сначала беру проблему, которая мне встречалась не раз и не выглядит слишком громоздкой. Затем решаю ее за несколько вечеров, собирая прототип. И потом в течение пары недель допиливаю проект до MVP, чтобы раскатить в дальнейшем на сервере. Так было с генератором фанфиков Fanfy Studio. Он был создан за три недели с нуля до полноценно функционирующего сервиса. Но в этот раз я решил устроить для себя некоторый челлендж: создать приложение в несколько подходов, записав абсолютно весь процесс на видео. В итоге я смог справиться за шесть дней и тридцать восемь часов суммарной работы.
В качестве проблемы для решения я решил взять создание превью для YouTube. Эти картинки крайне важны для итогового выхлопа с видео. Их весьма сложно создавать в Фотошопе, так как нужны серьезные навыки владения инструментами, чтобы создавать качественные заголовки и эффекты. Плюс нужно тратить много времени на кропотливое склеивание всех элементов в финальную картинку. Однако в последнее время вышло много нейронок, которые упрощают работу с изображениями. Например, нашумевшая Nano Banana показала, насколько легко теперь можно редактировать картинки. Поэтому я решил разработать простой сервис для создания превью для YouTube видео с помощью AI инструментов.
Чтобы у челленджа был понятный конец, нужно разобраться, что я вообще считаю завершенным продуктом. Завершенный сервис для меня - это решение, которое доступно для пользователей, выполняет свою функцию, имеет кое-какую монетизацию и более менее стабильно в плане доступности. Грубо говоря, сервис должен работать без моего участия как минимум неделю и как-то в теории окупаться.
Кстати, для стабильной работы многих сервисов критически важны качественные прокси. Например, недавно я делал проект с авто продажами через Telegram, и прокси в нем являлись одной из ключевых технологий. Без них вероятность быть забаненным в телеге увеличивается в разы. Однако у большинства провайдеров до сорока процентов грязных IP. Такой процент сильно усложняет автоматизацию. Это ведет к банам и потерям денег и времени. Поэтому в качестве прокси провайдера я использовал Node Maven. У них девяносто пять процентов чистых IP, сессии работают до двадцати четырех часов, есть качественно работающая фильтрация IP. И, кстати, у них появилась новая фича - Speed Filter, которая позволяет открывать сайты в три раза быстрее, по сути, со скоростью домашнего интернета. Она идеально подходит для управления аккаунтами в соцсетях, крипто-кошельками, исследованием конкурентов и любых действий в реальном времени. Чтобы автоматизировать без ограничений, переходите по ссылке в описании и пользуйтесь моими промокодами. По ним вы получите скидку пятьдесят процентов для первых пятидесяти пользователей и плюс сто процентов к доступному трафику.
Начинать такой сервис я предпочитаю с идеи, которая переводится в подробную документацию с описанием всей системы. Затем по доке пишется прототип, который должен хоть как-то работать и решать заданную проблему. После этого я обычно прикручиваю авторизацию, лимиты для пользователей и оплату. Потом дорабатываю дизайн, чтобы приложение не выглядело совсем уж плохо, и затем заливаю на сервак с уникальным доменом. В качестве финальных штрихов настраиваю мониторинг и метрики, чтобы понимать, что вообще происходит.
Но давайте по порядку. Первые тридцать пять минут работы над системой я ресерчил доступные по API модели в сервисе Fal.AI, смотрел, какие есть и как с ними работать в коде. Для простоты решил остановиться только на одной модели Gemini 2.5 Flash, взяв ее Text to Image и Image to Image версии. Также параллельно писал документацию с помощью ChatGPT 5 Thinking на Plus подписке за двадцать долларов, обозначая ключевые фичи и идеи для разработки. На мой взгляд, для написания документации выбор модели не слишком сильно влияет на результат. Берите любую из передовых: GPT, Claude или Gemini - в целом неважно. Гораздо важнее то, насколько вы сами хорошо понимаете документацию.
Затем еще пять минут ушло на то, чтобы разбить документацию на шаги, по которым я буду двигаться во время разработки. Под шагами я имею в виду некие стадии приложения, на каждом из которых оно не будет сломанным или рабочим наполовину. Оно будет успешно запускаться и хоть как-то жить, но, возможно, еще не иметь каких-то функций. Целью каждого этапа будет добавление новой фичи с сохранением стабильной работы системы. Я стараюсь строить процесс разработки именно таким образом, чтобы встречать и исправлять баги сразу, а не оставлять их на самый финал. Плюс такой подход очень хорошо сочетается с нейронками, так как небольшие задачи на улучшение существующего сервиса являются достаточно простыми для LLM.
Затем нужно тщательно проверить каждый пункт документации, разобрать, что в нем имеется в виду, и исправить, если это необходимо. GPT и другие нейронки очень часто любят загромождать документацию бесполезными примерами кода, чрезмерно сложным стеком и ненужными функциями. Это все нужно ревьюить и чистить самостоятельно. Я стараюсь оставлять в документации минимум описаний требований и стека. По технологиям предпочитаю брать Python плюс FastAPI на бэкенде плюс классический Next.js плюс Tailwind на фронте. И также в документации можно указывать какие-то специфичные для вашего проекта библиотеки. Для моего проекта это React Conva, которая позволяет работать с Canvas на фронтенде так, как будто это Photoshop. Она позволяет работать со слоями, титрами, картинками и многим другим.
Перейдем к разработке. Для написания проекта я использовал Claude Code со стандартным Sonnet 4, но через пару часов я уперся в лимит, и пришлось купить подписку Max за сто баксов. Это позволило мне местами использовать Claude Opus. Однако с ним нужно быть внимательнее, так как на этой модели очень легко упереться в ограничение Cloud по количеству запросов. В основном я использовал дефолтный тариф, где первые двадцать процентов тратится на Opus, а затем Cloud переключается на Sonnet. Если интересно, насколько эти модели отличаются, то можете посмотреть вот эти видео. Там я их сравниваю. В целом Claude Code хорош для таких спидранов, так как лимиты в нем заканчиваются достаточно редко и нет каких-то скрытых режимов, где нужно платить за каждый токен.
Разработка базового прототипа заняла примерно десять часов. С функционалом не было серьезных проблем, однако временами всплывали хитрые frontend-баги, так как приложение сильно завязано на тонкую работу на стороне браузера. Редактор - это практически чисто frontend-программа. Часто нейронка не могла пофиксить баги с первой попытки, поэтому приходилось сидеть немного дольше.
Вот каким правилом я придерживался при разработке с AI. Первое - выбирайте знакомые языки и фреймворки. Временами я пробую вайбкодить проекты на неизвестных мне стеках, но это всегда превращается в нечитаемую кучу кода. Поэтому если вы не хотите тратить время зря, то берите то, что работает, то, что вы знаете. Если не знаете ничего, то можете попробовать начать с такого же стека, как у меня.
Второе - избавляйтесь от сложных и малоценных фичей, делайте их в последнюю очередь. В текущем проекте я хотел сделать крутую систему версии, чтобы легко переключаться между разными вариантами картинок. Потратил час, чтобы завайпкодить такую систему, но ничего не вышло. Я откатился и забил. Она не была настолько важной, чтобы сидеть над ней полдня.
Из этого кейса следует еще одно очень важное правило: просите нейронку сделать только то, что вы сами понимаете, как можно сделать конкретно и пошагово. Если для вашего процесса вы можете нарисовать блок-схему со всеми ветвями и условиями, то только в таком случае вы можете делегировать разработку этой системы нейронке. Иначе же с девяносто процентами вероятностью она сделает что-то совсем другое или вообще не справится.
И следующий принцип это фиксирование корректно работающих состояний проекта с помощью Git. Git - это система, которая хранит в себе множество версий файлов проекта. Она позволяет сохранять, откатываться и разрабатывать несколько параллельных версий проекта, работая при этом в одной папке и не копируя файлы. Я фиксирую каждый успешно разработанный шаг в виде коммита в гите. Каждый раз, когда вы вызываете LLM и понимаете, что вам есть что терять, делайте коммит. Если что, вы всегда сможете его удалить. Обычно я также коммичу успешные промежуточные стадии. Затем, когда весь этап готов, я откатываю промежуточные коммиты с помощью git reset soft head и создаю один общий коммит с описанием реализованного шага. Если же шаг не удалось реализовать, то нажимаю кнопку Rollback, раскоммитив неудачные изменения.
Принцип пять: повторно используйте промпты, роллзы и агентов. Относительно недавно в Claude Code вышла новая фича под названием Agents. Агенты Claude - это отдельно работающие чаты со своими инструментами, доступом и контекстом. В рамках работы над проектом я использовал два кастомных агента под названием Frontend и Backend Minimalist, в которых описал инструкции по работе с кодом. Я попросил их делать только минималистичные и простейшие решения без усложнения кода. Вот их промпты. Также я не даю Claude запускать и перезапускать мои сервисы, чтобы не возникало путаницы, так как иначе нейронка очень часто будет натыкаться на конфликты в портах и будет править их в настройках, бесконечно запуская и настраивая кучу копий проекта. И все это часто скатывается в ситуацию, где frontend запущен сразу на трех репликах на портах три тысячи, три тысячи один, три тысячи два. Лучше все запуски и перезапуски выполнять вручную, контролируя количество запущенных реплик самостоятельно.
Прогресс в разработке был примерно такой: первый час - разработан базовый холст, импорт и экспорт изображений. По завершении второго часа была реализована возможность создавать проекты и выбирать, какой из них будет открыт для редактирования. Реализовано сохранение состояния холста на бэкэнде. На пятый час кодинга получилось реализовать базовую функцию удаления заднего фона. Затем еще тридцать минут ушло на реализацию генерации изображений и сорок минут на AI-редактирование. После этого еще пару часов на поддержку базовых текстовых слоев и еще час для возможности изменять эти текстовые слои с помощью AI. Затем следующие сорок минут я потратил на функцию AI-генерации на основе картинок из нескольких слоев, и базовый прототип был готов. Он работал очень ужасно, имел кучу багов, но в целом выполнял свою функцию. Вот как он выглядел. Можно было управлять слоями, генерировать и редактировать AI-изображения. Но превью слоев выглядели огромными, и не было нормальной индикации о состоянии джебы генерации. Также были странно работающие кнопки Undo, Redo, Clear, выделение и порядок слоев ломались при генерации или импорте изображений.
На этом этапе программа не имела никаких юзеров и форм входа, поэтому было самое время реализовать авторизацию. В качестве логина я всегда использую авторизацию через Google Account, она относительно простая в настройке, плюс не нужно слать никакие e-mail. Также более менее надежная в плане лимитов, так как пользователям довольно сложно создавать кучу аккаунтов из-за ограничений на стороне Google. Базовую работающую авторизацию получилось создать за четыре с половиной часа, так как во время разработки я заметил, что сижу на чистом React и не использую Next.js. Next.js нужен для удобного управления страницами и их адресами, поэтому я решил не пожалеть время на рефакторинг фронтэнда.
Также важной частью подобных сервисов является грамотное управление кредитами и лимитами пользователей. Для этого я создал таблицу Credits, куда будут начисляться квоты после пополнения средств. Эти квоты будут сверяться с успешно завершенными AI-генерациями, чтобы в итоге вычислить баланс пользователя. Подобным подходом я пользовался в продукте Fanfy, и он все еще неплохо работает. Плюс такой подход позволяет легко видеть историю пополнений через просмотр таблицы Credits.
В плане лимитов важно учитывать несколько моментов. Каждый запрос на генерацию картинки должен под капотом проверять баланс пользователя на стороне бэкэнда, чтобы минимизировать случаи злоупотребления генерацией. Баланс пользователя должен проверяться также на стороне фронтэнда, особенно когда его не хватает для совершения операции, чтобы показать пользователю уместное сообщение с просьбой пополнить баланс. И последний момент, который также супер важен для корректной работы, это отображение актуального баланса на фронтэнде, чтобы юзер понимал, сколько генераций у него осталось на данный момент. У меня ушел примерно час на реализацию такой системы лимитов. И, кстати, забегая вперед, проблем с ней в дальнейшем вообще не возникало. Она оказалась довольно надежной.
Перейдем к пополнению баланса, к оплате. Как вообще работают любые оплаты на всех сайтах? Сначала пользователь выбирает какой-то тариф и жмет на кнопочку оплатить. Фронтэнд шлет запрос на бэкэнд, указывая ID пользователя плюс ID тарифа. В рамках обработки этого запроса бэкэнд идет к платежному провайдеру, передавая в параметрах сумму, валюту, ID пользователя или ID операции. В ответ провайдер возвращает ссылку для совершения платежа. Затем эту ссылку бэкэнд возвращает на фронт, чтобы пользователь мог перейти по ней и оплатить. Как только юзер совершает платеж, провайдер делает обратный вызов нашего бэкэнда, так называемый webhook или callback. В этом вызове прежде всего мы получаем ID оплаты и статус платежа.А также опционально ID пользователя, ID тарифа или сумму оплаты. Исходя из этих параметров, back-end может пополнить виртуальный баланс юзера в нашей системе. В моем случае сервер выкидывает запись о пополнении средств в табличку Credits и все.
В качестве платежного провайдера я использовал сервис Love Top, так как у них ультра просто получить доступ, копить для генерации ссылок без сложных верификаций. Сервис имеет смешанные отзывы, но для MVP подойдет, так как оплаты проходят и деньги потом выводятся. Ссылка на этот сервис и на все остальные находится в описании.
Что еще важно понимать по оплатам? Самым главным фокусом при реализации модуля платежей должна быть надежность. Нужно внимательно просматривать код, изучать алгоритм, пока не поймешь каждую строчку кода и логику, которая стоит за ним. Без такого подхода очень легко напороться на жесткие дыры безопасности, и будет очень неприятно, если кто-то начнет рисовать фейковый баланс в вашей системе. На реализацию базового кода у меня ушел примерно час. Однако еще примерно час или два позже я потратил на исправление и отладку этого модуля, так как полный процесс оплаты можно произвести только на проекте, который успешно раскатан на сервере и имеет домен.
Перейдем к дизайну. Я сделал несколько попыток выработать нормальный стиль сайта. Самый удачный подход, на мой взгляд, получился, когда я нашел референс на Pinterest, стиль которых мне заходил. Я закинул примеры таких картинок в GPT и попросил накидать два артефакта. Первый это style-гайд для дизайнера с подробным описанием цветов, шрифтов и основных подходов. А второй это пример сверстанной страницы сайта с различными элементами, соответствующие первому гайду. Эти файлы я использовал как инструкцию для имплементации дизайна в мой код, скармливая их в контекст Cloud Code.
По оформлению сайта я сделал следующие выводы. Первое. Писать ChatGPT: "Сделай крутой дизайн", — не работает. В этом случае он рисует средний стандартный сайт, который уже невыносимо видеть. Он слишком заезженный. Лучше кидать референсы в виде картинок, это дает более уникальные результаты. И второе. Оформление очень сложно применить ко всему сайту с помощью кодинг-агента в один prompt, нейронка всегда что-то упускает. Поэтому лучше делать это постранично. Такой подход у меня отлично работал во многих проектах, вне зависимости от модели и инструмента. На создание и применение дизайна у меня ушло примерно семь часов. Много из-за того, что я пробовал разные стили, выбирал наилучший. Плюс во время применения дизайна я наткнулся на очень интересную проблему, о которой расскажу чуть позже. Пришлось ее пофиксить во время настройки дизайна. После применения стилей проект стал выглядеть вот так. Выглядит неплохо, хоть и есть недочеты. Я поправлю их позже.
После дизайна проект был, по сути, на финишной прямой. Пришло время раскатить его на сервак, подрубить домен и протестировать работу по сети, а не только локально. Самая важная штука, если речь идет о deploy, это докер. Докер это что-то вроде виртуальной машины, которая запускает в себе любые программы. В дополнение к нему я всегда беру docker compose, чтобы запускать не только отдельные сервисы, а целые связки программ. Например, back-end, front-end, базу данных и многое другое. Параметры запуска типа глобальных переменных, API-ключей, каких-то секретов и паролей обычно хранятся в ENV-переменных, которые складываются в файлике .env. На сервере лежат одни значения, а у вас на домашнем компе другие. Для всех своих проектов я прописываю докер-файлы, docker-compose.yml и проверяю работу всех сервисов связки в докере. Если все работает отлично, то пуляю файлы в GitHub репозиторий, чтобы затем оттуда потянуть их на сервак. Кстати, шаблон подобного проекта с авторизацией, логами, кредитами и оплатами смотрите по ссылке в описании. Думаю, будет полезно, если хотите пилить свой проект.
Для этого проекта я взял бомж-сервак на один CPU и 4 ГБ оперативы на хостингере. Локация, как всегда Германия, система Ubuntu. По цене немного дороговато, но зато нет проблем с верификацией и документами. Просто заплатил и все. Ссылка на хостинг, если что, в описании. Домен я выбирал достаточно долго, но в итоге остановился на прикольном имени ultrapreview.app. Взял его за десять баксов в год на Godaddy. Подрубил к серваку без проблем. Для раскатки моего docker compose на сервере я решил заюзать новую для меня штуку - Dockplay. Эта штука устанавливается довольно просто и позволяет деплоить и запускать сервисы с помощью интерфейса. Там можно подключить свой GitHub, чтобы клонировать код оттуда. Делается все через простые кнопочки, без всяких хардкорных конфигов. В разделе Environment заполнил секреты и пути и задеплоил через кнопочку Deploy. И, кстати, в Dockplay очень легко прикрутить любой домен к нужному сервису, прописав нужный порт и указав, что хочешь https-сертификат. В общем, Dockploy реально пушка. Рекомендую. Теперь использую его на всех своих серваках.
И перейдем к практически финальному этапу это шлифовка и отладка. Где-то шесть часов я потратил на фиксинг мелких UI-моментов, багов с авторизацией и проблем с оплатой. Также значительно упростил UI, избавившись от лишних кнопок и панелей. В качестве вишенки на торте сделал забавную главную страницу. Мне кажется, она получилась достаточно необычной, чтобы посетителю захотелось узнать, что там внутри. Вот такой вот сайт в итоге получился. И в качестве финалочки я прикрутил Plausible, как аналог Гугл аналитики, а также Grafana для анализа логов на бэке. Часто это важно для расследования инцидентов. Вот и все. Сайт готов для запуска юзеров.
Теперь расскажу про фейлы, на которые наткнулся во время этого Wipe Coding Challenge, а также выводы, которые получилось сделать.
Первое. Во время разработки, как правило, я мало смотрю в код. Я, скорее, стараюсь контролировать структуру папок, адреса и порты, библиотеки и используемые фреймворки. Однако небольшие детали могут серьезно подпортить результат работы с таким подходом. Во время применения дизайна я заметил, что любые изменения кода не влияют на результат, который отображается в браузере. Сайт как будто воспроизводится из какого-то кэша. Я начал исследовать конфиги и обнаружил пару параметров, которые влияют на кэширование. И после отключения этой функции я столкнулся с огромным количеством ошибок. Дело было в том, что пару коммитов назад я почистил лишние файлы и папки, которые выглядели абсолютно бесполезными, как будто Cloud Code случайно скопировал их. Но после отключения кэша я понял, что они были нужны. В итоге пришлось откатить это удаление через Git и нормально разобраться, какие файлы действительно нужны, а какие реально дубликаты. Потратил на это пару часов, но проблему решил.
И второй микро-кейс произошел тоже на фронте, на стадии дизайна. Claude неожиданно начал оформлять заново страницу логина, хотя я просил оформить страницу редактора. После отката изменений и детали...Дальше, при детальном изучении промпта, я понял, что правильно сослался на файл кода редактора, однако ошибочно прописал в промпте, что хочу отредактировать страницу логина. В общем, иногда проблемы возникают из-за невнимательности. И вместо того, чтобы сидеть и уговаривать модель все исправить и сделать как надо, проще откатиться и написать нормальный, понятный промпт.
Перейдем к выводам. Вот что я понял, пока я работал с нейронкой над этим проектом.
Во-первых, многие ленятся писать фидбек для нейронки нормально и развернуто. Как результат - получают поверхностный код, который и работает непонятно как. Я предлагаю писать обратную связь для нейронки так, как будто она человек. Не просто закидывать ей копипаст ошибки на сто строк, а описывать весь флоу, который ты проделал, какие кнопки нажал, где вылетела ошибка. Такой подход работает хорошо.
Во-вторых, на мой взгляд, разработка таких микропроектов происходит в виде некоторой пирамиды. На первом этапе ты долго делаешь очень ужасную, полурабочую версию за двадцать часов кодинга. Затем еще десять часов, и проект становится менее ужасным. И еще за пять он приобретает действительно приятный и рабочий вид. Первый этап самый тяжелый. А на последнем вайб кодинг идет с кайфом, так как этот этап выглядит как просто фиксинг мелких локальных моментов. А с этим нейронки справляются довольно хорошо. В общем, не нужно стараться все сделать идеально. Лучше сделать основу, а потом пройтись по ней очень много раз, улучшая результат.
В-третьих, вайб кодинг на текущем этапе развития нейросетей не требует от людей знания языков программирования или фреймворков. Однако для создания чего-то большего, чем простой скрипт, требуется понимание базовых концептов технологий, таких как back-end, front-end, json, API. И также нужен некоторый опыт в дебаггинге, просмотр конфигов и логов, использование DevTools в браузере. Эти навыки можно достаточно быстро развить до более-менее нормального уровня, если сделать несколько своих проектов.
И последний вывод. Спидран- подход хорош тем, что за несколько дней ты можешь получить готовый сервис, который решает проблему и дает ценность пользователям. Однако разработка без перерыва в течение более десяти часов очень сильно теряет в эффективности, так как мозг устает очень быстро. По моим ощущениям, он нагружается не совсем так, как в обычном программировании. В вайб-кодинге часто нет состояния потока, так как процесс выглядит иначе. Разработка с AI - это цикл вида: одна минута усиленных размышлений плюс десять минут ожиданий, пока нейронка не закончит работу. По моим ощущениям, лучше спидранить проекты по два-пять часов в день в течение недели, чтобы не перегружать мозг и лимиты в хоткод.
В общем, нейронки сейчас способны на многое. Они могут писать тысячи строк рабочего кода за один промпт, запускать и останавливать программы, доставать и анализировать массивы информации. Однако, чтобы делать с помощью AI что-то действительно цельное и полезное, нужно очень хорошо понимать процессы и концепции, которыми ты собираешься манипулировать. Чтобы работать эффективно, теперь нужно знать все: домен, в котором выполняешь работу, AI-подходы и инструменты, а также их устройство плюс общие принципы создания проектов и управления ресурсами.
Поэтому подписывайтесь на мой канал. Здесь я буду и дальше делиться опытом работы с ИИ, показывать свои эксперименты, сравнивать и анализировать инструменты, разбираться, как это использовать, и искать то, что действительно стоит нашего внимания. Подписывайтесь также на мой Telegram. Там я пишу немного чаще. Все ссылки в описании. Увидимся! Все. Господи.