Я собрала SaaS за шесть недель — и чуть не утонула на последних двадцати процентах
Полтора года назад я бы сказала любому фаундеру: закладывай на MVP полгода и бюджет от пары сотен тысяч рублей в месяц на разработку, и это по-хорошему. Сейчас я собрала рабочий продукт с оплатой, регистрацией и базовой аналитикой за шесть недель в одиночку, вечерами, без единого нанятого разработчика. И дело не в том, что я стала кодить в десять раз быстрее руками. Дело в том, что руками я теперь почти не кодю.
Стоимость входа в разработку обрушилась у меня на глазах
Как фронтендер я двадцать лет — ну ладно, десять — привыкла, что интерфейс верстается вручную, компонент за компонентом, а бэкенд пишет отдельный человек, которому нужно платить независимо от того, взлетит продукт или нет. Эта арифметика убивала половину идей ещё на старте: ты либо ищешь деньги под гипотезу, либо тратишь свои полгода жизни, чтобы просто узнать, нужен ли кому-то твой продукт. Сейчас я описываю ИИ задачу — «сделай форму регистрации с валидацией email и переходом на онбординг» — и получаю рабочий код за минуты, а не за день. Не идеальный, но рабочий. Это не философская смена, это чистая экономика: то, что раньше стоило условных двухсот тысяч и месяцы, теперь можно собрать за вменяемые деньги и недели. И когда стоимость ошибки падает на порядок, ты перестаёшь бояться пробовать пять идей вместо одной.
Что ИИ реально забирает себе, а что остаётся мне
Здесь важно не путать: ИИ не придумывает продукт и не решает, что в нём должно быть. Он забирает механику — то, что я как разработчик делала руками, но что никогда не было творческой частью работы. Бойлерплейт, типовые формы, миграции базы данных, тестовые заглушки, стандартная настройка проекта — вот это теперь пишется за меня, и я больше не трачу на это своё внимание. А архитектура — как разложить продукт на модули, что должно жить в базе, а что в кеше, где будет боль при масштабировании — это я по-прежнему решаю сама, потому что здесь нужен контекст всего продукта целиком, а не фрагмент задачи. Как дизайнер-любитель я вижу это ещё резче: ИИ отлично собирает интерфейс по моему макету, но сам макет — какая иерархия важности у элементов, что пользователь должен увидеть первым — придумываю всё ещё я. Инструмент не заменяет решение, он ускоряет его воплощение.
Стена восьмидесяти процентов — это не миф, я в неё влетела дважды
Первые восемьдесят процентов продукта дались мне действительно за пару недель, и это было настоящее опьянение скоростью. А потом начались тонкие места: интеграция платежей повела себя не так, как в документации, авторизация через несколько провайдеров конфликтовала друг с другом, а один баг с состоянием формы я и ИИ вместе гоняли по кругу часов пять, потому что модель предлагала пять разных исправлений, каждое из которых чинило симптом, но не причину. Это тот самый цикл, о котором сейчас много пишут: ты вроде бы уже почти закончил, но последний рывок вязнет в бесконечных «попробуй так — не помогло — попробуй эдак». В эти моменты легко потерять и время, и деньги на токены, гоняя одну и ту же проблему по замкнутому кругу вместо того, чтобы остановиться и подумать головой.
Что я делаю теперь, когда чувствую, что вхожу в петлю
У меня появилось правило: если третья попытка правки от ИИ не решила проблему, я останавливаюсь и сама читаю код, а не прошу модель попробовать ещё раз. Часто оказывается, что проблема на уровень выше — не в баге, который я просила исправить, а в архитектурном решении, которое я приняла двумя шагами раньше и которое ИИ физически не может увидеть, потому что видит только тот файл, с которым работает прямо сейчас. Второе правило — я перестала просить сразу большие куски функциональности. Чем крупнее задача, тем больше пространства для того, чтобы модель домыслила что-то не то. Маленькие, проверяемые шаги работают надёжнее, даже если кажутся медленнее. И третье — я обязательно читаю код, который получаю, а не просто запускаю и смотрю, работает ли. Не потому что не доверяю, а потому что через полгода поддерживать этот продукт придётся мне, и я должна понимать, что там внутри.
Я выпустила продукт недоделанным — и это было правильное решение
Самый сложный шаг для меня как для перфекциониста-разработчика — это отпустить продукт, в котором ещё нет половины из того, что я себе представляла. Но именно недоделанные версии дают честный сигнал: какие функции пользователи реально трогают, а какие я придумала себе в голове и была уверена, что они критичны. Я убрала из плана три фичи, на которые уже почти потратила время, просто потому что первые пользователи ни разу до них не дошли — им хватало базового сценария. Если бы я ждала полной версии, я бы потратила ещё месяц на то, что оказалось не нужно.
Вайбкодинг не сделал разработку простой — он сделал её быстрой там, где раньше была рутина, и оставил все сложные решения там же, где они были: в голове человека, который понимает продукт целиком. Если вы фаундер и думаете, что теперь можно вообще не разбираться в технической части — не выйдет. Но если вы откладывали идею, потому что боялись полугода разработки и бюджета, которого нет, — сейчас, кажется, самое время попробовать. Просто заложите время на последние двадцать процентов. Они всё ещё самые долгие.
Коротко
Разработчик Виолетта Кармышева собрала SaaS за шесть недель с помощью ИИ, но столкнулась с замедлением на финальных этапах из-за сложных багов и архитектурных проблем, которые ИИ не может решить без человека.
Вопросы и ответы
Сколько времени занимает создание SaaS с помощью ИИ?
Первые 80% продукта можно собрать за пару недель, но последние 20% могут занять значительно больше времени из-за сложных интеграций и багов.
Что ИИ может, а что не может делать при разработке SaaS?
ИИ справляется с рутинными задачами — формами, валидацией, миграциями, но не принимает архитектурные решения и не понимает контекст продукта целиком.
Почему последние 20% разработки SaaS самые сложные?
На финальных этапах возникают сложные баги, конфликты интеграций и архитектурные проблемы, которые ИИ не может решить без вмешательства разработчика.
Как не попасть в бесконечный цикл правок с ИИ?
Если три попытки ИИ не решают проблему, нужно остановиться, самому прочитать код и пересмотреть архитектурное решение, а не гнаться за быстрым исправлением.
Зачем выпускать недоделанный продукт?
Недоделанная версия позволяет получить реальную обратную связь от пользователей и понять, какие функции действительно нужны, а какие — нет.
Комментарии экспертов
Комментировать могут только эксперты портала (не автор статьи).
Пока нет комментариев.