Получили недавно интересный комментарий про кастомную разработку Шутку оценили, но решили обсудить тему подробно. Спойлер: SaaS или кастом – это не спор о том, что хуже или лучше. Это исключительно вопрос того, какая перед вами стоит задача и какой у вас масштаб. Давайте разбираться. Где SaaS работает идеально? Если брать чистый SaaS, без всяких доработок, то он всухую выигрывает в микро-, малом и отчасти среднем бизнесе. Там, где процессы супертиповые (и небольшие бюджеты). Отличный пример – маркетплейсы, вокруг которых выросла целая ниша обслуживающих SaaS решений (не меньшая по размеру, чем сами маркетплейсы). Везде одинаковые карточки товаров, одинаковые API’шки, одинаковые данные. Вы можете купить подписку за 5000 рублей и не думать про инфраструктуру, обновления и техподдержку. В этом сегменте SaaS – это единственный адекватный вариант. Про SaaS в крупном бизнесе Но как только мы переходим к Enterprise-сегменту, чистый SaaS перестает работать. У каждого крупного бизнеса свои уникальные процессы. Часто происходит следующее: корпорация покупает готовый SaaS (условный Битрикс или другую платформу), а дальше начинается: под хотелки компании дописываются кастомные модули, ядро платформы перекраивается, интеграторы городят сложные связки. По факту, это уже превращается в самую настоящую кастомную разработку, за которую платят огромные деньги, просто строится она на базе чужой коробки. Зачем тогда писать настоящий кастом с нуля? Основные сценарии: 1. Битва за проценты по правилу Парето. Возьмем ИИ-систему прогнозирования. Готовый SaaS за n-рублей сделает точность прогноза на 80%. Кастомная разработка будет стоить 10n рублей, но даст точность в 95%. Первые 80% достигаются легко, 85% – тяжело, а 95% – почти невозможно. На миллиардных оборотах эти 10-15% выигрыша приносят такие деньги, на фоне которых стоимость разработки кастома просто испаряется. 2. Очень старая, сложная инфраструктура. Пытаться костылями встроить в нее современную SaaS-коробку часто выходит сильно дороже, чем просто написать решение с нуля под себя. 3. Когда нужны полная внутриконтурность (on-premise) и жесткие метрики качества, куда ни одно публичное облако просто не пустят. Что с мифом про «г**но и палки»? Почему некоторые не любят кастом? Они видели плохой кастом🙂 Без тестов, без мониторинга, без нормальной архитектуры и – самое страшное – без владельца продукта (про это даже отдельную статью писали). Но давайте честно: это проблема кривого подхода конкретных исполнителей, а не формата кастомной разработки в целом.