Вы правда думаете, что SaaS-продукт можно заменить за 15 минут? 6 скрытых этапов, о которых не говорят
Недавно коллега прислал мне пост, который мы всерьез начали обсуждать вместе с грустными перспективами разработчиков в этом мире.
Человек проверял, сможет ли Claude Opus 4.5 клонировать полнофункциональный SaaS-продукт стоимостью в миллиард долларов и сделать его как минимум в 100 раз дешевле. Результат — полноценный клон форм-билдера, который обходится в 100 раз дешевле и был настроен за ~15 минут. Агент работал около 35 минут.
На этом фоне команда другого проекта вообще отказалась от подписки на task-менеджер: один человек за три дня сделал кастомный аналог.
Ведь все же ясно про ИИ:
- он уже пришёл, и каждый может создать продукт за пару кликов (даже без опыта в IT… тссс)
- можно клонировать даже системы, за которыми стоят сотни сотрудников
- платишь только за месячную подписку — не сравнить с коммерческими тарифами с обязательствами и оплатой за каждое рабочее место
- а лишние усложнения вроде поддержки высоких нагрузок нам и не нужны — запустим у себя на небольшой коллектив
Это все весело и задорно до тех пор, пока не началось использование.
И вот здесь я хочу немного развеять магическую ауру вокруг создания продуктов на вайбе.
Тут мне нужно сделать небольшую оговорку: я пишу это для не-технических специалистов, которые не знакомы с закулисной магией разработки продукта. Если вы опытный разработчик и знаете что делать - могу только пожелать успехов вашему проекту.
Какие этапы разработки и поддержки продукта скрыты от глаз потребителей
Тестирование
Тут не только про то, что основная функция работает. Тут про то, что система ведёт себя достаточно устойчиво при попытках пользователя использовать её так, как он видит (а ещё, по хорошему, и ограничиваясь только разрешенным функционалом).
А ещё, есть тестирование на регрессы (ошибки в старом функционале, которые внесли пока добавляли новый). И этим как раз любит грешить ИИ.
И, вдогонку, тестирование под нагрузкой и отказами.
Инфраструктура
Вы обычно не задумываетесь, сколько у вас микросервисов в продукте, где они развёрнуты и хватает ли им ресурсов для успешного взаимодействия.
А ещё, в каких странах и регионах (для международных рынков).
А ещё, как быть, если какой-то сервер поломался? Все потерпят или какие-то решения будут для разрешения этой ситуации.
И да, все это стоит денег. Сервера не бесплатны. Мониторинг не настраивается сам. Бэкапы не делаются по волшебству. Кто-то должен это все контролировать и оплачивать.
Система хранения и передачи знаний
Откровенно говоря, во многих компаниях, с этим не все гладко. Это, само по себе довольно обширная тема (такая, что по ней даже отдельные конференции проводятся).
Так вот. Если вы планируете пользоваться продуктом достаточно долго, то, скорее всего, он переживет в вашей компании того единственного разработчика, который создал этот продукт. И этот вопрос тоже встанет на повестке.
Безопасность
Периодически шаловливые ручки специалистов разного уровня подготовки залезают посмотреть, что у вас есть интересного в системе и чем можно поживиться.
Если вам кажется, что у вас иммунитет из-за маленького размера, то увы. Ко мне как-то забегали на тестовый сервер, шифровали базу из 10 записей и страшно угрожали. А вот свежий реальный случай на большой компании.
А есть еще видимые моменты, с которыми вы, наверняка, сталкивались
Поддержка
Это те терпеливые люди, которые принимают на себя гнев и негодование, когда что-то в системе не работает. Дополнительно исполняют роль линии психологической поддержки. И еще выполняют роль интерактивной документации в ситуациях когда кто-то не может (или не хочет) найти ответ на свой вопрос.
Управление изменениями
Сколько людей будет пользоваться продуктом — столько же (как минимум) идей по его развитию вы получите. Вместе с отчетами об ошибках, которые нужно когда-то исправить. Ведь все же знают, что софта без багов не бывает?
Так вот, кто-то должен собирать, анализировать, приоритизировать и планировать эти изменения.
И, учитывая всё это, предлагаю теперь принимать решение о переходе на самописные решения.
Если ваш вайб-кодер выглядит не так, то предлагаю всерьез задуматься над тем, потянет ли он все эти функции.
Еще мысль на подумать: у многих крупных продуктов открытый исходный код (open source). Т.е. их можно взять и самостоятельно развернуть на своих ресурсах. И даже это не останавливает их от развития и существования коммерческого решения рядом с ними.
Просто, половина желающих отвалится уже на этапе "подобрать подходящий сервер".
Безусловно, генерация кода с помощью ИИ дошла до серьезного уровня. И она заметно ускоряет разработку. Но говорить, что продукт на этом заканчивается не правильно.
Тут, на мой взгляд, как с рождением детей, все только начинается.
А какой у вас опыт с AI-клонами продуктов или самописными решениями? Получилось сэкономить или столкнулись с неожиданными сложностями? Делитесь в комментариях — очень интересно услышать реальные истории.
У меня, кстати, есть ТГ-канал, где я делюсь мыслями и наработками вокруг создания микро-продуктов: Мама стартапит