Автор разбирает типичную ситуацию в игровых студиях: команды хотят использовать внешние инструменты (бекенд, тулзы), но центральная техкоманда или CTO блокируют это решением «построим сами». Внешний продукт обычно зрелый, удобный, с поддержкой и понятной ценой. Внутренний — дольше в разработке, менее устойчивый и в итоге не дешевле, но это редко считается в цифрах.
Ключевая проблема — «бухгалтерская иллюзия». Лицензия внешнего сервиса видна как отдельная строка бюджета и требует одобрения, поэтому ощущается как реальный расход. Внутренняя разработка прячется в зарплатах и спринтах, помечается как «core tech» и психологически воспринимается как бесплатная: инженеры уже наняты. Но их время имеет альтернативную стоимость.
Автор предлагает смотреть на Total Cost of Ownership (TCO) — полную стоимость владения системой за весь срок жизни. В TCO входят пять компонентов, которые студии почти никогда не считают целиком.
1. Стоимость разработки (Build Cost)
Единственный компонент, который обычно хоть как-то учитывают: сколько инженеров, по какой полной стоимости, сколько месяцев. Для продакшн-бекенда с нуля это часто 3–8 инженеров на 6–18 месяцев, то есть миллионы до того, как первый игрок подключится. Плюс задержка: нужный бекенд через несколько лет вместо того, чтобы получить его сейчас, купив готовый.
2. Стоимость поддержки (Maintenance Cost)
По данным отраслевых исследований (IEEE, Gartner), ежегодная поддержка ПО стоит 15–25% от первоначальной стоимости разработки. За жизненный цикл системы поддержка «съедает» 60–80% всех затрат. Бекенд, который строили 18 месяцев, потребует эквивалент 3–4 месяцев инженерной работы каждый год только чтобы оставаться актуальным (обновления платформ, SDK, безопасность, версии движка). Внешний продукт уже обкатан другими, а внутренний вы тестируете в бою сами.
3. Стоимость эволюции (Evolution Cost)
Live-игры постоянно меняются: новые модели монетизации, платформы, поведение игроков. Каждое изменение бекенда — мини-проект, который отнимает те же ресурсы, что нужны на фичи игры. Это добавляется к поддержке и повышает общий TCO.
4. Стоимость потери знаний (Knowledge Retention Cost)
Редко учитываемый риск: уход ключевого инженера, который проектировал систему. В условиях дефицита специалистов это может означать месяцы потери продуктивности и год, пока новый человек разберётся в чужой архитектуре. Это прямой операционный риск, который обычно «прячут» в HR-допущениях.
5. Альтернативная стоимость (Opportunity Cost)
Самый высокий и наименее оцифровываемый компонент. Каждый инженер-месяц, потраченный на авторизацию, матчмейкинг, лидерборды и экономические тулзы, — это месяц, не потраченный на контент и фичи, которые реально отличают игру. Игроки не выбирают игру из-за того, что матчмейкинг написан in-house. Задержка релиза, урезанные live-ops и выход на рынок позже конкурентов — это реальная потеря, которая не видна в инвойсах.
Роль внутренних инженеров
Автор не призывает к аутсорсу всего. Напротив, лучшие инженеры должны работать над тем, что действительно уникально для вашей игры и не может быть куплено как продукт: специфическая логика, фичи, которые игроки заметят. Инфраструктуру «уровня гигиены» (матчмейкинг, лидерборды, базовый live-ops) рациональнее покупать у специализированных вендоров.
Решение: считать TCO, а не полагаться на интуицию
Решение build-vs-buy — это не вопрос принципов, а вопрос математики плюс ценности. Нужно честно сравнивать: полная стоимость внутренней разработки (включая поддержку, эволюцию, риски знаний и альтернативную стоимость) против цены внешнего решения. Студии, которые по умолчанию выбирают «строить сами», просто избегают увидеть реальные цифры.
Выводы
- Внутренние тулзы кажутся бесплатными из-за бухгалтерской иллюзии, но на самом деле дороже за счёт TCO.
- Поддержка и эволюция бекенда за годы обходятся дороже, чем сама начальная разработка.
- Риски потери ключевых инженеров и знаний существенно увеличивают стоимость владения внутренними системами.
- Главная альтернатива — время и фокус: каждый месяц на инфраструктуру отнимает месяц у фич, которые видит игрок.
- Рациональная стратегия — покупать стандартную инфраструктуру и использовать внутренних инженеров для уникальных конкурентных преимуществ игры.
