Разработка стоит слишком дорого или подрядчик пропал: как сократить затраты и довести продукт

Игорь, основатель Diaverse · 7 октября 2026 · 8 минут чтения

Две похожие ситуации. В первой подрядчик перестал отвечать, а продукт не доделан. Во второй команда работает, но каждый месяц обходится дороже, чем приносит продукт. Корень у них общий: владелец не контролирует свой продукт — код, доступы, приоритеты и расходы. Разберём, что делать в первые дни, как найти, куда уходят деньги, и как передать проект новой команде без переписывания с нуля.

Если подрядчик пропал: первые три дня

Подрядчик может пропасть по разным причинам: перегруз, конфликт, проблемы со здоровьем или с деньгами. Причина важна для разговора, но не для ваших первых шагов. Они одинаковые.

1. Соберите список доступов

Пройдите по списку и отметьте, что оформлено на вас, а что — на подрядчика.

Всё, что оформлено на подрядчика, — первый пункт разговора с ним.

2. Попросите передачу письменно

Напишите спокойно и конкретно: что передать (код, доступы, документацию, макеты) и к какому сроку. Посмотрите договор: кому принадлежат права на код и что сказано о передаче при расторжении. Это не юридическая консультация: если код и аккаунты не отдают, подключайте юриста.

3. Сделайте копию всего, до чего дотягиваетесь

Скачайте репозиторий, выгрузите базу данных, сохраните макеты из Figma, задачи из трекера и переписку с техническими решениями. Даже если подрядчик вернётся, копия лишней не будет.

4. Не начинайте переписывать с нуля

Первый порыв — «там всё плохо, переделаем». Иногда это правда, но решение нужно принимать после аудита, а не на эмоциях. Код, который работает у пользователей, стоит денег, даже если он некрасивый. Переписывание с нуля почти всегда занимает больше времени, чем кажется в начале.

Аудит: что выяснить за 1–2 недели

Новая команда или независимый разработчик должны ответить на пять вопросов.

• Собирается ли проект из репозитория и разворачивается ли на сервер по инструкции?
• Совпадает ли код в репозитории с тем, что сейчас работает у пользователей?
• Есть ли автоматический деплой, бэкапы и мониторинг ошибок?
• Какие части сделаны аккуратно, а какие придётся переписать, и во что это обойдётся?
• Где риски безопасности: ключи в коде, открытые админки, пароли в открытом виде?

Итог аудита — список «оставляем / чиним / переписываем» с оценкой каждого пункта. Только после этого можно решать, как и с кем двигаться дальше.

Если разработка просто слишком дорогая

Вторая ситуация тише, но обходится дороже: команда на месте, работа идёт, а продукт движется медленно и каждый месяц стоит всё больше.

Посчитайте полную стоимость месяца

Сложите всё: зарплаты или счёт подрядчика, налоги, сервисы и подписки, а также ваше время на управление командой. Теперь посмотрите, что за этот месяц дошло до пользователей. Если за месяц вышли только исправления ошибок и десяток задач в статусе «почти готово», дело не в ставках, а в процессе.

Найдите, куда уходят деньги

По опыту Diaverse есть четыре главных места, где деньги уходят впустую.

• Лишние роли. На одного человека, который делает продукт, приходятся несколько тех, кто координирует. Каждая встреча оплачивается по ставкам всех участников. Посчитайте, сколько людей пишут код и рисуют интерфейс, а сколько их согласовывают.
• Долгие согласования. Задача неделями ждёт решения. Измерьте, сколько дней проходит от идеи до релиза.
• Функции, которыми не пользуются. Откройте аналитику и найдите функции, которыми пользуется малая доля людей. Если аналитики нет, это первая задача: без неё вы управляете вслепую.
• Маркетинг до проверки спроса. Трафик в продукт, из которого люди уходят после первого дня. Пока удержание низкое, рекламный бюджет утекает, как вода из дырявого ведра.

Что меняем

• Цель на 1–2 месяца и одна главная метрика. Всё, что не двигает её, ждёт.
• Заморозка лишнего. Функции, которыми не пользуются, не развиваем, а новые «на всякий случай» не начинаем.
• Один ответственный за приоритеты и процесс, с которым вы говорите.
• Короткие спринты и демо каждую неделю. Вы видите работающий результат, а не отчёт о часах.
• Фиксированный бюджет в месяц. Новая задача не добавляется сверху, а заменяет другую такого же размера. Так объём и расходы не растут сами по себе.
• Код, хостинг и аккаунты — на вас. Тогда смена команды перестаёт быть катастрофой.

Своя команда или внешняя: как сравнить честно

Когда разработка дорогая, возникает вопрос: оставить свой штат или передать проект внешней команде. Сравнивайте полную стоимость, а не только ставки.

• Своя команда: зарплаты и налоги, месяцы на поиск и ввод людей в проект, ваше время на управление, риск, что уйдёт единственный человек, который знает архитектуру.
• Внешняя команда: фиксированная сумма в месяц. Но проверьте, что в неё входит: ведение проекта, дизайн, DevOps, аналитика. Попросите список того, что не входит, — он важнее списка того, что входит.
• Сравнивайте разработку с разработкой. Рекламный бюджет, хостинг и платные сервисы — отдельные статьи расходов при любом варианте.

Если решили сокращать свою команду, не делайте этого одним днём. Оставьте на переходный месяц людей, которые знают устройство продукта, и попросите их описать развёртывание, архитектуру и известные проблемы. Знания, которые живут только в голове одного разработчика, — самый дорогой долг проекта.

Как передать проект новой команде

1. Доступы и копии. Всё из первого раздела: без этого передача невозможна.
2. Аудит и список «оставляем / чиним / переписываем».
3. Небольшая первая задача, заметная пользователям. Она проверяет главное: новая команда умеет выпускать изменения в работающий продукт.
4. Крупные доработки — только после этого.

Если прежний подрядчик на связи, оплатите ему одну-две встречи по передаче проекта. Это дешевле, чем неделями разбираться в чужом коде вслепую.

Тревожные признаки при выборе новой команды

• Просят оплату за весь проект вперёд.
• Код будет лежать в их репозитории «до конца работ».
• Нет регулярного демо, только отчёты.
• Каждое изменение — отдельная доплата.
• Нет одного ответственного, с которым вы говорите.

Кейс Diaverse: тот же объём разработки за меньшие деньги

Diaverse — наше собственное мобильное приложение: шагомер и игра с питомцами, в App Store с марта 2024 года. Полтора года назад мы собрали для него классическую команду: проджекты, менеджеры, поддержка, разработчики, дизайнеры. Двигались медленно, а результат нас не устраивал.

За это время мы поняли, где деньги уходили впустую: лишние роли, долгие согласования, функции, которые никому не нужны, маркетинг до проверки спроса. Огромные зарплатные фонды, отделы и слои менеджеров — так IT строили раньше. Рынок изменился: сегодня разработку Diaverse ведут сильные специалисты с современными инструментами, и тот же объём работы обходится в разы дешевле.

Это не значит, что в любом проекте получится так же: многое зависит от продукта и от того, что уже написано. Но порядок действий тот же — сначала контроль над кодом и расходами, потом скорость.

Чек-лист: продукт под вашим контролем