Если вы читаете это в начале 2026 года, вы, вероятно, побывали хотя бы на одной встрече, где кто-то произносил фразу «должны ли мы создать это или купить?» и наблюдал, как комната разделилась на два лагеря: тех, кто хочет сделать всё самостоятельно, и прагматиков, которые просто хотят, чтобы что-то работало к следующему кварталу. Я наблюдал за этим достаточно раз, чтобы понять, что редко бывает явный победитель — есть только более обоснованные решения.
Вопрос «создать или купить» раньше был проще. У вас было либо время и деньги, либо их не было. Вы создавали или покупали. В 2026 году ситуация изменилась. ИИ меняет сроки разработки. Экосистема поставщиков matured превратилась в нечто похожее на реальный рынок. Таланты по-прежнему дорого стоят. И давление с целью максимизации каждого доллара означает, что вы не можете позволить себе ошибиться.
Итак, давайте поговорим о том, чем вы должны владеть, чем вы должны поделиться и как принять это решение, не впадая в паралич анализа.
Фундаментальный вопрос, который никто не задаёт
Прежде чем углубляться в рамки и матрицы, есть один вопрос, который важнее всех остальных: определяет ли это программное обеспечение ваше конкурентное преимущество?
Если да, создайте его. Владейте им. Контролируйте каждый пиксель, каждый вызов API, каждый запрос к базе данных. Свобода экспериментировать, адаптироваться и выделяться стоит каждой строки кода и каждой сессии отладки в полночь.
Если нет — если это необходимость, но не отличительная черта — покупка обычно является правильным шагом. Энергия вашей команды ограничена. Тратьте её там, где она превращается в реальное преимущество.
Это различие настолько важно, что я видел, как компании тратили миллионы на создание внутренних систем расчёта заработной платы, когда они могли бы зарегистрироваться в существующем решении за полдня. Тем временем я также наблюдал, как компании пытаются купить путь к уникальным ощущениям от продукта и в итоге получают универсальные решения, которые не подходят.
Разница между этими компаниями? Те, кто сначала задал себе сложный вопрос.
Стоимость: почему счёт-фактура лжёт вам
Давайте поговорим о деньгах, но будем честны. Та таблица в Excel, которую вы видели на совещании по бюджету? Она неполная.
Создание: математика выглядит плохо, но есть поворот сюжета
При создании программного обеспечения затраты максимальны и жёстки. Вам нужны дизайнеры, разработчики, архитекторы, менеджеры по продукту, тестировщики и, возможно, специалист по DevOps, который знает Kubernetes. Вы рассчитываете на значительные начальные инвестиции.
Вот в чём дело: эти затраты складываются по-разному в зависимости от того, как вы их рассматриваете.
Первый год: высокие. Очень высокие. Вы можете рассчитывать на 500–2 миллиона долларов в зависимости от размера команды и масштаба. Все видят эту цифру и морщатся.
Пятый год: история меняется. Вы владеете активом. Ваши разработчики знают его наизусть. Скорость добавления функций увеличивается. Вы не платите маржу поставщику. Стоимость единицы функций снова начинает выглядеть разумной.
Ловушка? Предполагая, что затраты первого года каким-то образом сократятся. Они не сокращаются. Если ваши разработчики уйдут, вам нужно будет нанять и ввести в курс дела новых. Патчи безопасности не устанавливаются сами собой. Инфраструктура не обслуживается сама собой. Вы взяли на себя постоянную ответственность.
Покупка: предсказуемая ловушка
Покупка поначалу выглядит дёшево. Абонентская плата, предсказуемая, лёгкая для бюджета. Это на самом деле опасно.
Что происходит в масштабе? Лицензионные сборы часто растут нелинейно. Вы начинаете с 100 пользователей по 50 долларов за пользователя в месяц. Вдруг у вас 1000 пользователей, и срабатывает ценовой диапазон поставщика — теперь это 100 долларов за пользователя в месяц, или они вводят плату за каждую функцию, или они полностью отменяют ваш ценовой диапазон.
Реальное уравнение затрат выглядит так:
| Год | Создание (на заказ) | Покупка (SaaS) |
|---|---|---|
| Первый год | 750 тысяч долларов (5 разработчиков × 150 тысяч долларов) | 50 тысяч долларов (100 пользователей × 50) |
| Второй год | 900 тысяч долларов (повышение зарплаты, новый сотрудник) | 75 тысяч долларов (рост на 30%, повышение тарифа) |
| Третий год | 950 тысяч долларов (затраты на обслуживание) | 120 тысяч долларов (масштабирование, новые функции) |
| Четвёртый год | 1,1 миллиона долларов (апгрейды, рефакторинг) | 220 тысяч долларов (повышение цен поставщика) |
| Пятый год | 1,2 миллиона долларов (зрелость, стабильность) | 380 тысяч долларов (зависимость от поставщика) |
| Итого за 5 лет | 4,9 миллиона долларов | 845 тысяч долларов |
Посмотрите на это, и покупка победит на бумаге. Кроме того, посмотрите на пятый год в сценарии покупки — вы в ловушке. Поставщик знает, что вы зависимы. Цены не отражают вашу способность договариваться; они отражают его способность извлекать выгоду.
Сценарий создания? Вы достигли устойчивого состояния. Ваши затраты предсказуемы. Вы не ведёте переговоры с кем-то, кто контролирует вашу судьбу.
Настоящий ответ: ни одно число не является верным в изоляции. Вам нужно смоделировать свой конкретный сценарий, включая самые опасные затраты, о которых никто не говорит — затраты на переход позже.
Скорость: альтернативные издержки, которые вы не можете игнорировать
Покупка программного обеспечения происходит быстро. Очень быстро. Вы можете перейти от проблемы к решению за дни, а не за месяцы.
Создание занимает время. Сбор требований. Проектирование. Кодирование. Тестирование. Доработка. Если вы всё делаете правильно, вы говорите о трёх-девяти месяцах для чего-то значимого. Для сложных систем год или больше не является необоснованным.
Но вот где повествование становится интересным: скорость имеет значение только в том случае, если проблема срочная.
Если вы решаете задачу «нам нужен отчёт о расходах в следующем квартале», купите что-нибудь. Альтернативные издержки создания — пропущенные рыночные окна, задержка других функций — слишком высоки.
Если вы решаете задачу «нам нужен отчёт о расходах, который интегрируется с нашей собственной системой биллинга и обрабатывает наши уникальные требования к рабочему процессу», временные затраты на попытки приспособить готовое решение могут превысить временные затраты на создание. Время на настройку складывается незаметно. Ограничения поставщика разочаровывают незаметно. В конце концов, вы платите за инструмент, который вроде как работает, а ваша команда тратит 30% своего времени на преодоление его ограничений.
Настоящий вопрос: каковы альтернативные издержки выбора, который вы НЕ делаете?
Выбирайте скорость, когда: важны сроки выхода на рынок, вам нужно доказательство концепции или решение действительно нестратегическое.
Выбирайте создание, когда: время на создание на самом деле короче, чем время на настройку и адаптацию, или проблема достаточно важна, чтобы индивидуальное соответствие превзошло быстрое решение.
Настройка: граница между контролем и сложностью
Создание программного обеспечения означает, что вы контролируете каждую функцию, каждое дизайнерское решение, каждый выбор пользовательского опыта. Вы создаёте для своих конкретных потребностей, без компромиссов.
Покупка программного обеспечения означает, что вы играете в чьей-то чужой песочнице. Вы получаете варианты конфигурации, возможно, некоторые настройки, но границы — это чьё-то другое видение.
Это имеет большее значение, когда ваше отличие зависит от опыта. Если вы продаёте потребителям и UX является конкурентным преимуществом, создание имеет смысл. Вы не можете идти на компромисс там.
Если вы создаёте внутреннюю инфраструктуру? Можете ли вы жить с достаточно хорошими инструментами, которые вашей команде не нужно поддерживать? Обычно да.
Вот практическая структура:
Создавайте, если:
- Пользовательский опыт является ключевым для вашего продукта.
- Ваш рабочий процесс действительно уникален (а не просто немного отличается).
- Вам нужна плотная интеграция с другими системами, которые вы контролируете.
- Решение должно развиваться так же быстро, как и ваш продукт.
Покупайте, если:
- Функция является стандартной, а не отличительной.
- Рабочий процесс является стандартной отраслевой практикой.
- Интеграции существуют и работают достаточно хорошо.
- Вас устраивает дорожная карта поставщика.
Таланты: проверка реальности
Для создания программного обеспечения требуются сильные инженерные команды. Не только разработчики — вам нужны архитекторы, которые мыслят системно, менеджеры по продукту, которые понимают требования, специалисты по DevOps, которые занимаются инфраструктурой, эксперты по безопасности, которые не являются второстепенными.
Найти и удержать этих людей дорого, всё более конкурентоспособно и действительно сложно в 2026 году.
Покупка программного обеспечения требует меньше технических ресурсов. Ваша команда фокусируется на настройке, персонализации, использовании, обучении. Вы не поддерживаете инфраструктуру. Вы не отлаживаете глубокие системные проблемы. Вы управляете инструментами.
Эта асимметрия имеет огромное значение.
Если ваша команда состоит из 15 человек и один из них — старший инженер, создание является азартной игрой. Этот один человек становится узким местом. Они уходят, и вы застряли. Покупайте.
Если ваша команда состоит из 50 человек с сильной инженерной культурой, надёжным конвейером по найму и людьми, которые хотят владеть системами, которые они создают, создание становится более жизнеспособным. Вы можете поддерживать системы в долгосрочной перспективе.
Честная оценка: как долго останутся ваши ключевые люди? Насколько сложно будет их заменить? Эти ответы напрямую определяют вашу способность поддерживать индивидуальное программное обеспечение.