Фраза «SaaS умер» в последнее время набирает популярность. Суть аргумента такова: раз мы живём в эпоху, когда ИИ умеет писать код, нам стоит перестать платить ежемесячные подписки за SaaS и просто создавать нужные системы собственными силами.
В моей компании Emooove последние несколько месяцев мы полностью посвятили себя созданию внутренних систем собственными силами. Пройдя через это на практике, я познал и успехи, и болезненные уроки. Сегодня я хочу поделиться своим взглядом на нарратив «SaaS умер» — взглядом, основанным на этом реальном опыте.
Сразу уточню: я пишу это с позиции пользователя и создателя систем, а не провайдера SaaS.
Удивительная эпоха, когда любой может создавать системы
Прежде всего, исходный тезис: появление Claude Code действительно открыло эпоху, когда «систему может собрать кто угодно». Это не преувеличение.
В Emooove руководитель направления подбора, проработавшая у нас всего два месяца, создала внутреннюю ATS — систему отслеживания кандидатов (Applicant Tracking System). Она не инженер, у неё ноль опыта в разработке. И тем не менее она собрала рабочую систему, которая закрывает всё: от импорта кандидатов до управления отбором и дашбордов.
Более того, сейчас мы разрабатываем внутреннюю систему для повышения операционной эффективности и качества нашего основного бизнеса — агентских услуг по продажам. Я лично занимаюсь этим каждый день, и не прошло ещё и двух недель с момента старта, а мне уже кажется, что мы на пороге чего-то действительно хорошего.
Понятно, почему людям хочется говорить «SaaS умер»: ведь можно собрать внутри компании систему, которая иначе обошлась бы в десятки или сотни тысяч иен ежемесячной подписки.
Однако не всё так гладко
Вот тут самое главное. Когда мы действительно попробовали, всё оказалось далеко не так радужно.
1. Сопровождение невероятно сложно
Как ни крути, системы можно собирать «на лету», поэтому они обретают форму очень быстро. Но из-за того, что требования проработаны не до конца, остаётся много шероховатостей.
В случае с нашей ATS мы столкнулись, например, с таким:
- Кандидаты, которые должны были импортироваться, не импортировались.
- Цифры на дашборде почему-то глючили.
- Не хватало критически важных кнопок, и операции вставали.
Мы столкнулись со множеством «недочётов, которые замечаешь только после начала использования». А с внутренней системой поддержки продаж был даже случай, когда утром мы вдруг не смогли к ней подключиться — экран просто не открывался.
Конечно, это можно частично исправить, если тщательнее прорабатывать требования или улучшать систему по ходу дела. Но в это время страдает нормальная операционная деятельность. Если начинать разработку с ожиданием, что будет «легко и быстро», можно оказаться в неприятной ситуации. Я понял, что начинать нужно не с настроем «собрал и закончил», а с настроем «собрал — и продолжаешь чинить».
Поскольку масштаб нашего найма невелик, мы переживём, даже если ATS на время встанет. Но я содрогаюсь при мысли, если бы это была система с множеством заинтересованных сторон. С ростом числа пользователей и масштаба влияния потери от одного сбоя увеличиваются, а уровень сложности взлетает до небес.
Если во внутренних системах с этим ещё можно мириться, то при создании чего-либо для внешней продажи или обращённого наружу, например формы обратной связи, нужно быть предельно осторожным.
2. UI/UX никогда не становится отполированным
Я осознал это, когда собирал систему сам: качество отделки получается, мягко говоря, средним.
Экраны, которые ИИ генерирует в первый раз, выглядят «прилично», но при реальном использовании детали оказываются топорными. Да, в конце концов можно довести всё до ума, давая ИИ инструкции снова и снова, но это требует одержимости и времени. Скорее всего, большинство людей на полпути просто плюнут и смирятся.
Интерфейсы SaaS отполированы, потому что профессиональные дизайнеры годами воплощали в них обратную связь пользователей; это не достаётся бесплатно.
3. Проблема безопасности
Это самое страшное.
Даже не инженеры могут использовать Claude Code, чтобы собирать функциональность и UI/UX в режиме «авось сойдёт». Но можно ли точно так же, с наскока, разобраться в безопасности? По крайней мере у меня — нет. Аутентификация, управление правами доступа, реагирование на уязвимости — «работает» и «безопасно» это две совершенно разные вещи.
В нашем случае нам, к счастью, повезло: у нас есть человек с опытом инженера по безопасности, и мы обязательно поручаем эту часть ему. Но даже так остаётся тревога. От одной мысли об организации без экспертов, которая размещает данные клиентов в системе, собранной на коленке, и делает её публичной, меня бросает в холодный пот.
Логика «жить или умереть» ошибочна
Я перечислил минусы собственной разработки, но, если честно, плюсов тоже много.
- Можно построить решение, которое идеально подходит вашему бизнесу.
- Если что-то нужно исправить, можно сделать это уже на следующий день.
- Почти нет ежемесячных расходов.
- Компания получает ноу-хау и уверенность в том, что «мы сами можем строить системы».
Проблема в попытке свести всё к вопросу «Выживет SaaS или умрёт?». Выбор между SaaS и собственной разработкой зависит от ситуации в компании. Основываясь на своём опыте, я выделяю пять пунктов, которые стоит взвесить:
Пункт 1: Есть ли у вас свои инженеры?
Если нет, вы провалитесь в таких областях, как безопасность, где не-инженер не справится на авось. Самое страшное — возможность собрать функциональность, даже не осознавая опасностей. Поворотный момент — сможете ли вы найти опытного специалиста, который проверит ключевые области.
Пункт 2: Количество заинтересованных сторон
Если их слишком много, потери при сбое огромны, а уровень сложности резко возрастает. И наоборот, небольшим организациям экспериментировать легче: если что-то встанет, можно просто извиниться. Реалистично начинать с операций с небольшим радиусом влияния.
Пункт 3: Внешние и внутренние системы
Если система внутренняя, риски в случае сбоя ограничены. Но для всего внешнего даже одна утечка информации может быть необратимой. SaaS позволяет переложить часть ответственности на вендора, а при собственной разработке вся ответственность лежит на вас. Ценность «проверенного спокойствия» SaaS растёт для всего, что обращено наружу.
Пункт 4: Можете ли вы выделить человеко-часы на сопровождение?
Сопровождения требуется больше, чем вы думаете. Собственная разработка — это не «собрал и закончил», а «продолжай чинить». Готовы ли вы начать с таким пониманием? Если подойти к делу спустя рукава, вас завалят исправлением багов, и это будет давить на основной бизнес.
Пункт 5: Нравится ли вам заниматься ИИ-разработкой?
В конечном счёте всё сводится к этому. Это более утомительно и сложно, чем кажется, а когда ИИ тебя не слушается, это просто бесит (смеётся). Готовы ли вы довести дело до конца, несмотря на это? Это отличное время для тех, кому такое в кайф, но я не думаю, что это можно вытянуть на одном чувстве долга.
Итог: SaaS не умер. Просто вариантов стало больше
В заголовке я использовал слово «провал», но точнее было бы «много раз чуть не провалились». Мы продолжаем собственную разработку, потому что у нас есть опытные инженеры, наша организация всё ещё небольшая, системы предназначены в основном для внутреннего использования, мы готовы вкладываться в сопровождение и, самое главное, я сам этого хочу. Можно сказать, мы занимаемся этим, потому что находимся в привилегированном положении, где выполняются все пять пунктов.
И наоборот, если компания, которая не соответствует этим условиям, воспримет «SaaS умер» буквально и попытается перевести на собственные рельсы свои ключевые операции, она действительно провалится.
SaaS не умер. Просто возможность «строить самому» теперь открыта для всех. Спокойно оцените ситуацию в своей компании и используйте и SaaS, и собственную разработку. Разве это не правильный способ действовать в эту удобную, но шаткую эпоху?
