ПЯТНАДЦАТЬ ЛЕТ НАЗАД Я ВИДЕЛ ЭТУ ГРАНИЦУ
Пятнадцать лет назад я часто видел эту границу значительно чётче.
Большой каталог. Сложные фильтры. Большой трафик. Сложные интеграции.
В определённый момент разговор становился относительно простым. CMS доводила нас до этой точки. Дальше мы строили.
Сегодня у меня значительно больше опыта принятия таких решений, чем пятнадцать лет назад.
И мне менее комфортно принимать их быстро.
Не потому что я хуже понимаю софт. Потому что софт по обе стороны решения изменился. Платформы стали сильнее. CMS-экосистемы стали способнее. Интеграции стали проще. Кастомный софт стал быстрее в разработке. А теперь AI снова сдвигает экономику разработки.
Старая форма вопроса была простой: строить или покупать?
Я больше не уверен, что это правильный вопрос.
Вопрос, который я задаю чаще сейчас: что нам нужно решить сегодня, а что реальность решит за нас позже?
Я КОГДА-ТО ВИДЕЛ ЭТУ ГРАНИЦУ
Помню, когда Shopify был значительно более простым продуктом. Помню, когда многие CMS-платформы имели очевидные ограничения.
Можно было посмотреть на бизнес с большим каталогом товаров, сложной фильтрацией, необычными интеграциями, растущим трафиком и длинным списком операционных требований и сказать: мы это перерастём.
Иногда ты почти видел этот приближающийся момент. Платформа не была плохой. Бизнес просто становился другой проблемой.
Сегодня эту границу увидеть сложнее.
Современные коммерческие платформы уже не простые инструменты, которые я помню. Они стали экосистемами. Сам Shopify теперь поддерживает значительно более широкий B2B и extensibility слой, чем продукт, который многие из нас помнят с прошлых лет. Его текущая платформа охватывает B2B функционал, кастомные опции storefront, API, расширяемость checkout и растущую экосистему вокруг ядра commerce-движка.
То же самое случилось с софтом в целом.
Бизнес теперь может запуститься с SaaS-продуктом, подключить несколько сервисов, настроить workflows, добавить интеграции и решить проблемы, которые раньше сразу вели нас в кастомную разработку.
Для нового или относительно небольшого бизнеса ответ может быть очевидным. Не строй то, что уже можешь купить и протестировать завтра. Запускайся. Смотри, работает ли бизнес. Смотри, как ведут себя клиенты. Смотри, что реально нужно команде.
Нет никакого приза за владение 80 000 строк кода до того, как придёт твой первый сотый клиент.
Но изменилось и кое-что ещё.
Строить стало доступнее. Современные фреймворки, облачная инфраструктура, API, распределённые команды разработки, и теперь AI-ассистированная разработка, всё это сдвинуло часть экономики кастомного софта.
Исследовательская работа 2026 года, изучавшая именно эту проблему, называет это напряжение прямо: доступность сторонних решений и возможность кастомной разработки выросли одновременно.
Это не противоречие. Это вся сложность.
ПОДПИСКА ЗА $500 РЕДКО ОСТАЁТСЯ СИСТЕМОЙ ЗА $500
Я видел это много раз.
Компания начинает с одной подписки. Цена выглядит разумной. $500 в месяц. Может, $800. Может, $1000. По сравнению с кастомным софтом, решение выглядит почти нелепо простым.
Потом бизнесу нужно что-то ещё. Ещё один сервис. Потом интеграция. Потом коннектор, потому что первые две системы не совсем разговаривают друг с другом. Потом модуль. Потом более высокий план, потому что доступ к API или другая нужная функция живёт в другом тарифе. Потом ещё один инструмент для отдела, чей процесс не вписывается в первую систему.
Одна подписка притягивает другую.
Решение за $500 никогда не было системой за $500.
Это не аргумент против SaaS. Софтверные подписки решают огромные проблемы. Они дают компаниям доступ к годам продуктовой разработки, инфраструктуры и операционного опыта без необходимости строить эти способности самим.
Но стеки подписок накапливаются. И иногда накапливаются тихо.
2026 SaaS Management Index от Zylo сообщает, что средние расходы на SaaS в их датасете выросли на 8% год к году, тогда как среднее количество приложений оставалось практически неизменным. Также отчёт сообщает в среднем о 36% лицензий, которые не используются относительно рекомендуемых уровней утилизации. Данные происходят от SaaS-management вендора, и это стоит учитывать, но паттерн знаком каждому, кто внимательно смотрел на зрелый software-стек.
Проблема не всегда в том, что компании покупают плохой софт. Иногда они покупают софт для бизнеса, которым представляют, что станут.
Это нам понадобится в конце года. Отдел продаж будет это использовать. Мы планируем зайти на другой рынок.
Позже этот процесс станет значительно сложнее. Поэтому компания добавляет инструмент. Или апгрейдит план. Или подключает сервис.
Будущее не приходит.
Подписка приходит. Каждый месяц.
Software-стеки накапливают предположения. Некоторые становятся реальными требованиями. Некоторые нет. Счёт не знает разницы.
ИНОГДА SAAS ЭТО ИССЛЕДОВАНИЕ
Именно здесь, я думаю, компании делают решение build versus buy слишком постоянным, слишком рано.
Иногда клиент приходит к нам с чётким запросом. Ему нужна CRM. Коммерческая платформа. Конфигуратор. Внутренняя бизнес-система. У него есть бюджет на кастомную разработку. Он может даже прийти уже убеждённым, что кастомный софт более серьёзное решение.
Но есть проблема.
Бизнес может ещё недостаточно понимать свой будущий процесс. У владельца одна идея. У маркетинга другая. Продажам нужно что-то другое. Операционный отдел уже нашёл три исключения, которые никто не обсуждал на первой встрече. Приходит внешняя маркетинговая команда. Присоединяется специалист, ответственный за другой канал.
Каждый описывает будущую систему. И каждый может быть прав насчёт проблемы, которую видит сейчас.
Это нормально. Мне нравится эта часть проектов. Живой бизнес не чист. Разные люди давят на систему с разных сторон, потому что переживают разные части реальности.
Ошибка не в наличии этого хаоса. Ошибка в превращении каждого текущего мнения в постоянную инфраструктуру.
Иногда лучшее решение взять существующий SaaS-продукт и запуститься. Не потому что мы считаем, что компания должна пользоваться им вечно. Потому что компании нужно научиться.
Пусть реальные клиенты войдут в процесс. Пусть реальные заказы пройдут через систему. Пусть команда найдёт обходные пути. Пусть люди игнорируют фичу, которую все настойчиво считали критической. Пусть появятся исключения.
Через шесть месяцев разговор другой.
Мы больше не спрашиваем, как ты представляешь работу этого процесса. Мы можем спросить, как он реально работал.
На это значительно дороже ответить кастомным кодом.
Иногда SaaS не альтернатива кастомному софту. Иногда SaaS исследовательская фаза перед кастомным софтом.
А иногда исследование даёт ответ, которого ты не ожидал. Платформа работает. Стоимость приемлема. Интеграции стабильны. Команда адаптируется. Бизнесу не нужен кастомный софт.
Хорошо. Оставайся там.
Цель никогда не заключалась в том, чтобы найти повод строить. Цель заключалась в том, чтобы найти правильную инфраструктуру для бизнеса.
МОЖЕТ, ТЫ ПРОСТО НЕ МОЖЕШЬ ЭТО ПОСТРОИТЬ
Однажды я спорил с клиентом о фиче, которую он хотел, чтобы мы построили.
У него был бюджет. Он был готов платить. Я продолжал спрашивать, действительно ли бизнес нуждается в этой фиче. В какой-то момент он разозлился.
Может, ты просто не можешь это построить. Или у тебя нет ресурсов. Твои конкуренты могут это сделать. Ты не можешь. Мне пойти к ним?
Хотелось бы сказать, что я оставался полностью рациональным.
Не оставался. Это меня задело.
Хорошо, сказал я. Мы это построим.
Но я попросил об одном.
Через шесть месяцев мы вернёмся и проверим, насколько важной на самом деле была эта фича.
Работа стоила около $18,000. Мы это построили.
Через шесть месяцев мы встретились, чтобы обсудить новые задачи. Я не забыл тот спор. Поэтому спросил: можем посмотреть на ту фичу?
Мы посмотрели.
Никто ею не пользовался. Не меньше, чем ожидалось. Недостаточно, чтобы оправдать стоимость. Никто.
Фича работала. Клиент был готов платить. Мы были способны её построить. Деньги были доступны.
И всё равно нам не стоило это строить.
Я не рассказываю эту историю, потому что был прав. Я не был уверен. У меня были сомнения. Это разные вещи.
И мне точно не понравилось обнаружить, что клиент потратил около $18,000 на то, чем никто не пользовался.
Но этот опыт изменил то, как я подхожу к кастомной разработке.
Сегодня, когда клиент говорит мне, что фича важна, я часто задаю другой вопрос.
Когда она тебе реально нужна?
Наверное, ближе к концу года.
Тогда, возможно, мы не строим это сегодня. Мы запускаем то, что бизнес понимает сейчас. Наблюдаем. Учимся. Если фича станет реальным требованием, мы её тогда построим.
Мы до сих пор работаем с тем клиентом.
ИНОГДА Я ОБЪЯСНЯЮ СОФТ ЧЕРЕЗ ДОМ
Я работал и с цифровой, и с физической архитектурой. Поэтому иногда объясняю клиентам software-решения, рассказывая о зданиях.
Софт ощущается гибким. Поле в базе данных не выглядит дорогим. Ещё одна роль пользователя не выглядит структурной. Ещё один статус. Ещё одна интеграция. Ещё одно исключение. Это код. Мы можем изменить код.
Здание делает ту же ошибку значительно легче для понимания.
Годы назад мы работали над большой частной резиденцией для очень амбициозного клиента. Он хотел лифт в доме. Он также хотел бассейн на террасе.
Бассейн на террасе не декоративная идея. Вода тяжёлая. Нагрузка меняется. Инженерия меняется. Конструкцию нужно спроектировать под то будущее, которое ты описываешь.
Поэтому террасу усилили. Конструктивные работы, связанные с запланированными нагрузками, добавили примерно $100,000. Дом также подготовили под идею лифта.
Бассейн так и не построили. Лифт тоже.
Будущее исчезло. Инфраструктура, построенная под него, осталась.
Я видел, как воображаемые требования становились кодом. Я также видел, как они становились бетоном. Ошибка удивительно похожа.
Софт легче изменить, чем бетон. Счёт нет.
Можно убрать фичу, стоившую $18,000. Можно удалить код. Можно отключить интеграцию. Можно упростить workflow. Деньги не возвращаются.
Поле в базе данных ощущается дешевле армированного бетона. Но достаточное количество предположений в итоге становится структурным. Они влияют на модель данных. Интерфейсы. Тесты. Интеграции. Людей, которые поддерживают систему.
В какой-то момент ты обслуживаешь здание под бассейн, который так и не построили.
Каждое предположение входит в архитектуру так, будто будущее уже наступило.
Именно поэтому я осторожен с будущими требованиями. Не потому что компании должны перестать планировать. Не потому что амбициозные владельцы должны стать менее амбициозными. Мне нравятся амбициозные проекты.
Но есть разница между тем, чтобы оставить разумный путь открытым, и тем, чтобы заставить сегодняшнюю инфраструктуру платить полную цену за завтрашнее воображение.
ДАЖЕ КОГДА МЫ СТРОИМ КАСТОМНОЕ, МЫ НАЧИНАЕМ ПРОСТО
Кастомная разработка не означает строить всё.
Звучит очевидно. На практике это удивительно сложно.
Как только компания решает инвестировать в кастомный софт, проект психологически меняется. Люди начинают открывать ящики. Есть список с прошлого года. У кого-то есть таблица. Маркетинг вспоминает фичу, которую обсуждали шесть месяцев назад. У продаж семь исключений. Владелец уже думает о следующем рынке.
И поскольку мы всё равно строим кастомный софт, каждая идея начинает звучать дешевле.
Мы уже здесь. Давайте добавим это сейчас. Позже будет сложнее. Нам это точно понадобится.
Может быть.
Но каждая фича, которую мы строим, создаёт обязательство по обслуживанию.
Всё, что ты строишь, начинает стареть в день, когда ты это завершаешь.
Фича не бесплатна после завершения разработки. Она должна продолжать работать, пока бизнес меняется вокруг неё.
Поэтому один из простейших вопросов, которые я задаю: тебе реально нужна эта фича?
Да. Абсолютно. Мы планируем её внедрить.
Когда?
Наверное, ближе к концу года.
Хорошо. Тогда, возможно, она нам сейчас не нужна. Давайте запустим сначала эту часть. Протестируем процесс. Посмотрим, как люди пользуются системой. Выясним, выживет ли требование контакт с бизнесом.
Если выживет, мы это построим.
Не строй кастомно будущее предположение, если можешь подождать, пока оно станет текущим требованием.
Это не про быстрое строительство плохой первой версии. Меня не интересует выпустить что-то плохое и назвать это MVP.
Это про постройку той части системы, которую бизнес уже понимает. А потом дать реальности спроектировать вместе с нами следующий слой.
ПРАВИЛЬНОЕ РЕШЕНИЕ МОЖЕТ ИЗМЕНИТЬСЯ
Сейчас мы работаем над новой версией продукта для бизнеса, который знаем уже более пяти лет.
Оригинальный продукт построили на open source CMS. На тот момент это было правильное решение. Бизнесу не нужна была большая кастомная платформа только потому, что мы могли её построить.
CMS дала нам основу. Мы развивали её. Расширяли. Подключали, что нужно было подключить. Бизнес работал.
Потом бизнес вырос. Каталог стал сложнее. Логика фильтрации стала требовательнее. Интеграции накопились. Сам продукт стал другой системой.
Поэтому мы посмотрели на решение снова. На этот раз кастомная разработка имела больше смысла.
Не потому что кастомный софт тайно был правильным ответом пять лет назад. Предыдущее решение было правильным. Бизнес изменился. И когда бизнес изменился, уравнение изменилось вместе с ним.
Это та часть, которую, я думаю, многие компании упускают.
Software-решение становится частью истории компании. Мы пользуемся этой CRM. Мы на этой платформе. Мы построили собственную систему. Мы выбрали эту архитектуру пять лет назад.
Предложение постепенно превращается из решения в факт. Никто больше не задаёт исходный вопрос.
Но бизнес, который отвечал на тот вопрос, может уже не существовать. Его объём изменился. Его команда изменилась. Его клиенты изменились. Его процессы изменились. Его software-поставщики изменились. Экономика разработки изменилась. Способности платформ изменились.
Почему ответ должен оставаться постоянным?
Те же исследователи приходят к похожему выводу с более формального направления. Их фреймворк отображает решения build versus buy через четыре измерения: стратегию, характеристики приложения, стоимость и бюджет, и риск, и трактует само решение как что-то, что может смещаться, когда эти измерения смещаются.
Они построили модель под это.
Я пришёл к тому же месту, наблюдая, как бизнесы перерастают решения, которые когда-то были вполне разумными.
КУПИТЬ, НАСТРОИТЬ, РАСШИРИТЬ, ПОСТРОИТЬ
Я больше не думаю об этом как о двух дверях.
КУПИТЬ
Используй существующий продукт. Запускайся быстро. Плати за доступ. Пусть кто-то другой несёт большую часть бремени платформы.
НАСТРОИТЬ
Продукт уже решает проблему. Твоя задача сделать так, чтобы он отражал бизнес, не притворяясь, что каждое предпочтение требует кода.
РАСШИРИТЬ
Основная система работает. Конкретной части бизнеса нужно больше. Интегрируй. Добавь слой. Строй по краям, где это имеет смысл.
ПОСТРОИТЬ
Бизнес понимает процесс. Система важна на годы, не на месяцы. Экономика оправдывает владение и обслуживание. Требования достаточно специфичны, чтобы принуждение компании в чужую модель создавало реальную операционную проблему.
И даже тогда, начинай просто.
Этот спектр всё чаще виден и в текущих дискуссиях о build versus buy. Последние фреймворки описывают выбор менее как бинарный, и более как построить, купить, или расширить существующую платформу.
Но мы бы добавили ещё одну вещь.
Это не четыре уровня зрелости. Постройка не финальный босс софта. Компания, пользующаяся SaaS, не менее продумана, чем компания с кастомной платформой.
Иногда самое умное архитектурное решение заплатить за продукт и больше никогда не думать об этой части бизнеса. Иногда это владеть системой. Иногда это арендовать сначала, научиться и пересмотреть позже.
Архитектура должна служить бизнесу. Бизнес не должен изображать сложность ради архитектуры.
ПЕРЕСЧИТАЙ
Если клиент спрашивает нас сегодня: Shopify, SaaS, open source CMS или кастомный софт?
Мы не можем ответить из самого вопроса. Даже с неограниченным бюджетом мы не можем честно сказать: кастомный.
Нам нужно понять бизнес.
Что он делает сегодня? Что реально сложно? Какие процессы реальны, а какие запланированы? Чем компания ожидает заниматься через пять лет? Сколько реально стоит текущий software-стек после подписок, модулей, коннекторов и интеграций?
Что произойдёт, если вендор изменит цены? Что произойдёт, если команда кастомной разработки исчезнет? Может ли компания обслуживать то, чем хочет владеть? Нужна ли бизнесу эта функция сейчас? Когда она реально ею воспользуется?
И, возможно, самое важное: знает ли компания достаточно об этом процессе, чтобы сделать решение постоянным?
Экономика движется с обеих сторон. SaaS-портфели не обязательно растут по количеству приложений, но расходы продолжают расти по текущим отраслевым данным. При этом AI-ассистированная разработка заставляет исследователей и компании пересматривать часть исторической экономики строительства софта, хотя текущие исследования также предупреждают, что идея о том, что AI просто делает SaaS устаревшим, преувеличена.
Именно поэтому мы думаем, что многим компаниям стоит пересмотреть этот вопрос.
Не потому что SaaS плохой. Не потому что кастомный софт вдруг стал дешёвым. Не потому что AI изменил всё за ночь.
Потому что переменные сдвинулись.
И твой бизнес, вероятно, тоже сдвинулся.
Software-решение, которое ты принял пять лет назад, могло быть полностью правильным. Это не делает его правильным сегодня.
Фича, в которой ты уверен, что она понадобится в декабре, может стать критической. Или ею никто никогда не воспользуется.
Платформа, которую ты арендуешь, может стать фундаментом компании на следующее десятилетие. Или она может научить тебя точно тому, чем должна стать твоя собственная система.
Вопрос не в том, можем ли мы это построить. Всё чаще можем.
Вопрос не в том, существует ли уже софт, способный это сделать. Всё чаще существует.
Более сложный вопрос, знает ли бизнес достаточно, чтобы сделать решение постоянным.
А если не знает, возможно, самое дорогое, что ты можешь построить сегодня, это будущее, которое ты лишь воображаешь, что тебе нужно.
- Поделиться
-
-
-
-
