Маркетинг и продажиПсихологияОбразованиеИИИнвестицииБизнес и управлениеHRЛичный брендЭлектронная коммерцияCryptoВсе ▾
Стартапы · · 4 мин чтения

Я собрала SaaS за шесть недель — и чуть не утонула на последних двадцати процентах

Полтора года назад я бы сказала любому фаундеру: закладывай на MVP полгода и бюджет от пары сотен тысяч рублей в месяц на разработку, и это по-хорошему. Сейчас я собрала рабочий продукт с оплатой, регистрацией и базовой аналитикой за шесть недель в одиночку, вечерами, без единого нанятого разработчика. И дело не в том, что я стала кодить в десять раз быстрее руками. Дело в том, что руками я теперь почти не кодю.

Стоимость входа в разработку обрушилась у меня на глазах

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

Что ИИ реально забирает себе, а что остаётся мне

Здесь важно не путать: ИИ не придумывает продукт и не решает, что в нём должно быть. Он забирает механику — то, что я как разработчик делала руками, но что никогда не было творческой частью работы. Бойлерплейт, типовые формы, миграции базы данных, тестовые заглушки, стандартная настройка проекта — вот это теперь пишется за меня, и я больше не трачу на это своё внимание. А архитектура — как разложить продукт на модули, что должно жить в базе, а что в кеше, где будет боль при масштабировании — это я по-прежнему решаю сама, потому что здесь нужен контекст всего продукта целиком, а не фрагмент задачи. Как дизайнер-любитель я вижу это ещё резче: ИИ отлично собирает интерфейс по моему макету, но сам макет — какая иерархия важности у элементов, что пользователь должен увидеть первым — придумываю всё ещё я. Инструмент не заменяет решение, он ускоряет его воплощение.

Стена восьмидесяти процентов — это не миф, я в неё влетела дважды

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

Что я делаю теперь, когда чувствую, что вхожу в петлю

У меня появилось правило: если третья попытка правки от ИИ не решила проблему, я останавливаюсь и сама читаю код, а не прошу модель попробовать ещё раз. Часто оказывается, что проблема на уровень выше — не в баге, который я просила исправить, а в архитектурном решении, которое я приняла двумя шагами раньше и которое ИИ физически не может увидеть, потому что видит только тот файл, с которым работает прямо сейчас. Второе правило — я перестала просить сразу большие куски функциональности. Чем крупнее задача, тем больше пространства для того, чтобы модель домыслила что-то не то. Маленькие, проверяемые шаги работают надёжнее, даже если кажутся медленнее. И третье — я обязательно читаю код, который получаю, а не просто запускаю и смотрю, работает ли. Не потому что не доверяю, а потому что через полгода поддерживать этот продукт придётся мне, и я должна понимать, что там внутри.

Я выпустила продукт недоделанным — и это было правильное решение

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

Вайбкодинг не сделал разработку простой — он сделал её быстрой там, где раньше была рутина, и оставил все сложные решения там же, где они были: в голове человека, который понимает продукт целиком. Если вы фаундер и думаете, что теперь можно вообще не разбираться в технической части — не выйдет. Но если вы откладывали идею, потому что боялись полугода разработки и бюджета, которого нет, — сейчас, кажется, самое время попробовать. Просто заложите время на последние двадцать процентов. Они всё ещё самые долгие.

Коротко

Разработчик Виолетта Кармышева собрала SaaS за шесть недель с помощью ИИ, но столкнулась с замедлением на финальных этапах из-за сложных багов и архитектурных проблем, которые ИИ не может решить без человека.

Вопросы и ответы

Сколько времени занимает создание SaaS с помощью ИИ?

Первые 80% продукта можно собрать за пару недель, но последние 20% могут занять значительно больше времени из-за сложных интеграций и багов.

Что ИИ может, а что не может делать при разработке SaaS?

ИИ справляется с рутинными задачами — формами, валидацией, миграциями, но не принимает архитектурные решения и не понимает контекст продукта целиком.

Почему последние 20% разработки SaaS самые сложные?

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

Как не попасть в бесконечный цикл правок с ИИ?

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

Зачем выпускать недоделанный продукт?

Недоделанная версия позволяет получить реальную обратную связь от пользователей и понять, какие функции действительно нужны, а какие — нет.

Виолетта Кармышева
Автор · Разработчик
Виолетта Кармышева

Код должен решать проблему пользователя, а не радовать эго разработчика.

Профиль эксперта на ExpertRank →

Комментарии экспертов

Комментировать могут только эксперты портала (не автор статьи).

Пока нет комментариев.