Что нужно знать до начала
Это редакционный материал по выбору подрядчика, а не юридическая консультация. Выдержки про права на код, договорные конструкции и 152-ФЗ — практические ориентиры, а не образцы договорных формулировок: конкретные пункты сверяйте с квалифицированным юристом.
Цены, сроки и кейсы конкретных подрядчиков в материале не сравниваются — статья про устойчивые ошибки выбора, а не про рейтинг рынка.
Выбор студии разработки для MVP — это решение, которое определяет не только то, как будет написан код, но и сможете ли вы вообще на нём дальше расти. Большинство дорогих провалов закладываются не в процессе разработки, а в момент выбора подрядчика — и почти всегда по одним и тем же причинам. Ниже — десять ошибок, которые мы видим чаще всего, почему каждая из них стоит дороже, чем кажется, и как её избежать.
01 · Берут самое дешёвое предложение
Самая дорогая ошибка обычно маскируется под экономию. «Соберём на Tilda, прикрутим WordPress, найдём фрилансера» — это работает ровно до первой реальной нагрузки или первой нетривиальной фичи.
MVP — это не одноразовый прототип, а первая продакшен-система, на которой вы будете учиться и итерироваться. Если её нельзя безопасно менять, она не выдержит этого обучения, и «дёшево собранное» придётся переписывать — уже за полную стоимость, с потерей темпа.
В российских реалиях 2026 добавляется ещё и вопрос стека: он должен работать под текущими санкционными ограничениями и требованиями локализации данных (152-ФЗ), а не только «запуститься на коленке».
Как избежать. Сравнивайте не цену запуска, а стоимость владения и переделки. Дешёвый старт, который через полгода требует переписывания, дороже честной архитектуры с первого дня. Спросите подрядчика, какие решения он закладывает в первую версию ровно для того, чтобы её не пришлось ломать, когда продукт начнёт расти.
02 · Соглашаются на «посчитаем по часам» без фиксированного scope
Почасовая оплата без зафиксированного объёма перекладывает весь риск неопределённости на вас. И дело не в нечестности подрядчика — дело в стимулах: при почасовке его метрика успеха — загрузка часов, а не результат.
Это классическая проблема принципала-агента: исполнитель рационально оптимизирует свои показатели, а не ваш исход, и у него нет встроенной причины завершать быстрее. Исследования провалов ИТ-проектов (Standish и другие из года в год) ставят размытый scope на вершину причин срыва бюджетов и сроков — это не специфика отдельной студии, а структурный эффект.
Как избежать. Фиксируйте scope до начала разработки — для этого и существует архитектурный спринт: понять, что входит в первую версию, какие риски, какой стек и какой объём. Оплату привязывайте к понятным результатам и зафиксированным этапам, а не к часам как таковым. Открытая почасовка без границ — это договор, в котором у вас нет потолка, а у подрядчика нет дедлайна.
03 · Не проверяют senior-состав команды
Стандартная модель роста агентства — leverage: выиграть проект под именами сильных сеньоров, а делать руками джунов с маржой сверху. Вам показывают на пресейле тимлида и архитектора, а ежедневно код пишет джун, которого вы не видели до подписания.
Для MVP это особенно опасно: ранние архитектурные решения определяют всё последующее, и их нельзя доверять тому, кто учится на вашем проекте. Стоимость переделки модели данных, ролей или биллинга после первых платящих клиентов обычно несопоставима со стоимостью этих решений на старте.
Как избежать. Спрашивайте прямо — кто именно будет писать код и принимать архитектурные решения, в каком составе, и сколько времени сеньоры реально проведут в проекте, а не на пресейле. Попросите познакомиться с людьми, которые будут работать, а не с теми, кто продаёт. Хорошая практика — пилотный спринт, где вы видите команду в работе до основного контракта.
04 · Не уточняют, где хранится код
Это вопрос, который кажется техническим, но на деле он про контроль над вашим активом. Если репозиторий лежит в личном или корпоративном аккаунте подрядчика, при расставании вы рискуете остаться без собственного кода — а вместе с ним без истории, документации и возможности продолжить с другой командой.
В России 2026 к этому добавляется второй слой риска: доступ к GitHub нестабилен. В мае 2026 системы мониторинга (OONI) и отдельные медиа фиксировали ухудшение доступности сервиса из РФ; Роскомнадзор заявлял, что доступ не ограничивает, и домен формально не в реестре запрещённых — но напряжение реальное, а сам GitHub принадлежит Microsoft и обязан соблюдать санкционное законодательство США.
Существуют отечественные альтернативы — GitVerse (СберТех), GitFlic (ГК «Астра»), self-hosted GitLab Community Edition, Mos.Hub — но их экосистема слабее GitHub-овской, а перенос репозиториев, пайплайнов и интеграций — это месяцы и реальные деньги.
Как избежать. Репозиторий должен с первого дня находиться в вашем аккаунте или организации, с правами администратора у вас, а не у подрядчика. Учитывая нестабильность доступа, заранее обсудите резервное или российское размещение либо зеркало. Код, к которому у вас нет полного доступа, — это не ваш код.
05 · Платят за выезды менеджеров, а не за разработку
В смете легко не заметить, что значительная доля бюджета уходит на координацию, статусные встречи и аккаунт-менеджмент, а не на сам продукт. Это та же история со стимулами: накладные расходы агентства оплачиваете вы, и чем тяжелее процесс, тем больше «движения», которое выглядит как работа, но не приближает запуск.
Симптомы: десятки часов в неделю на синки с тремя менеджерами; статусы, на которых обсуждают предыдущие статусы; «защитные» документы, которые никто не читает; еженедельные отчёты, в которых нет прироста сделанного.
Как избежать. В смете должно быть видно, сколько уходит на разработку, а сколько — на менеджмент, и второе должно быть пропорционально размеру проекта, а не наоборот. Один-два внятных канала связи и регулярный демо-ритм важнее армии менеджеров, выставляющих часы за присутствие. Если на этапе пресейла менеджеров больше, чем инженеров, это уже что-то говорит.
06 · Игнорируют документацию и передачу
Если знание о системе живёт только в голове конкретного разработчика, вы заложник этого человека — то, что в инженерии называют bus factor (что будет, если ключевой человек уйдёт). MVP без документации и без зафиксированных архитектурных решений — это система, которую невозможно передать новой команде без долгой и дорогой «археологии».
«Археология» — это когда новая команда тратит недели на чтение кода, угадывание намерений и реконструкцию связей вместо того, чтобы развивать продукт. Эту работу оплачиваете вы, причём дважды: за то, что её не сделали изначально, и за то, что её делают сейчас.
Как избежать. Заранее договоритесь, что в результат входят базовая документация и Architecture Decision Records (ADR) — короткие записи о том, какое решение принято, какие варианты рассматривались и почему выбран этот. Это то, что позволяет новому разработчику (или вам при смене подрядчика) понять логику системы за часы, а не за недели. И это тот же артефакт, который пригодится при технической проверке инвестором или партнёром.
07 · Не запрашивают реальные кейсы в продакшене
Красивое портфолио на сайте и работающий в продакшене продукт — разные вещи. Лендинги, макеты и «концепты» ничего не говорят о том, способна ли команда довести систему до реальных пользователей, нагрузки и эксплуатации.
Особенно показательны не сами кейсы, а то, что с ними происходит сейчас. Один кейс, который три года живёт в продакшене, обновляется и развивается, ценнее десяти красивых дизайн-макетов в Behance.
Как избежать. Просите ссылки на живые продукты в продакшене и контакты клиентов для рекомендаций. Хороший вопрос: «что вы строили, что работает прямо сейчас, и можно ли поговорить с заказчиком?» Если в ответ показывают только дизайн-макеты и обещания — это сигнал. Если в ответ ссылаются на NDA по всем кейсам без исключения — отдельный сигнал.
08 · Соглашаются на длинные сроки без понятных milestone
«Сделаем за полгода» без промежуточных, проверяемых вех — это полгода, в течение которых вы не можете оценить прогресс и не можете дёшево остановиться, если что-то идёт не так.
Зрелая разработка устроена итеративно: частая, безопасная поставка маленькими кусками снижает риск каждого шага. Standish даже измерил цену медленных решений — команды, которые принимают решения быстро, успешны кратно чаще тех, кто откладывает выбор «до большой ясности».
Как избежать. Разбивайте работу на короткие вехи с осязаемым результатом на каждой, чтобы у вас были и видимость прогресса, и точки выхода. Хороший ритм для MVP — двухнедельные итерации с демо работающего сценария, а не «отчёт о проделанной работе». Длинный срок без milestone — это ставка вслепую; вехи превращают её в серию обратимых решений.
09 · Не обсуждают, что будет, если разойтись
Никто не хочет обсуждать развод на старте отношений — и именно поэтому об этом не думают, пока не становится поздно и дорого. Передаются ли вам исключительные права на код? В чьём аккаунте репозиторий и данные? Что с доступами, секретами, инфраструктурой? Если эти вопросы не закрыты в договоре, расставание превращается в одностороннюю дверь без пути назад.
Отдельный сюжет — переходное обслуживание: что подрядчик обязан сделать в момент завершения работ, чтобы вы или другая команда могли продолжить без двухнедельного простоя.
Как избежать. До начала работ зафиксируйте в договоре:
- передачу исключительных прав на результат (отчуждение по 1234 ГК РФ — это типовой механизм, но конкретные формулировки должен подбирать ваш юрист);
- принадлежность репозитория, данных и доменов клиенту;
- порядок передачи доступов, секретов и инфраструктуры при завершении или приостановке работ;
- порядок переходного периода и его стоимость.
Для проектов с персональными данными добавьте отдельный раздел: кто и как обеспечивает требования 152-ФЗ, как фиксируется роль обработчика, что происходит с ПДн при расторжении. Это практический ориентир, а не образец договорной формулировки — конкретные пункты сверяйте с юристом.
10 · Выбирают аутстаффинг вместо продуктовой команды
Аутстаффинг (аренда рук) и продуктовая команда отвечают за разное.
Аутстафф-разработчик отвечает за выполнение задач, которые вы ему ставите. Решения о том, что строить и как, остаются у вас. Это удобно, если у вас есть свой техлид, продуктовый менеджер и ясный план — тогда вы покупаете именно дополнительные руки, которые делают то, что вы спроектировали.
Продуктовая команда отвечает за результат — за то, что построенное действительно работает, и берёт на себя мышление, а не только исполнение. Это разница между «вы купили часы разработки» и «вы купили исход».
Для MVP, где половина ценности — в правильных архитектурных и продуктовых решениях, аренда исполнителей оставляет самые дорогие решения на вас, и это часто заметно только постфактум.
Как избежать. Определитесь, что вам нужно. Если у вас есть свой техлид и ясный план — аутстафф уместен и эффективен. Если вы покупаете MVP «под ключ» и рассчитываете на ответственность за исход — вам нужна команда, отвечающая за результат, а не за выполненные тикеты. Ошибка — купить первое, считая, что купили второе, и обнаружить разницу, когда риск уже на вас.
Как этим пользоваться
Сведём в короткий чек-лист для разговора с подрядчиком. Спросите прямо:
- Кто именно пишет код и принимает архитектурные решения в вашей команде, и сколько времени эти люди реально на проекте.
- Зафиксирован ли scope до начала разработки и к чему привязана оплата — к часам или к результатам этапов.
- В чьём аккаунте репозиторий и как решается вопрос доступа к коду в условиях 2026 (резерв, зеркало, российский хостинг).
- Что входит в документацию и передачу — техническая документация, ADR, переходный период.
- Какие живые продукты в продакшене можно посмотреть и с какими заказчиками поговорить.
- Как разбита работа на вехи и какой результат демонстрируется на каждой.
- Что прописано на случай расставания — права, код, данные, доступы, переходное обслуживание.
- Отвечает подрядчик за результат или за выполнение задач — и какой формат вам реально нужен.
Студия, которая отвечает на это спокойно и конкретно, — та, с которой стоит работать. Студия, которая уходит от ответов, — сама ответ.
Частые вопросы
Дешёвая разработка MVP — это всегда плохо? Не всегда, но дешёвый старт, который нельзя безопасно менять и нужно переписывать через полгода, дороже честной архитектуры с первого дня. Сравнивайте стоимость владения и переделки, а не цену запуска.
Почему важно, в чьём аккаунте лежит код? Потому что код — ваш актив. Если репозиторий в аккаунте подрядчика, при расставании вы можете остаться без собственного продукта. В России 2026 добавляется нестабильность доступа к GitHub — поэтому репозиторий должен быть в вашей организации, с вашими правами администратора, и стоит заранее продумать резервное или российское размещение.
Чем продуктовая команда отличается от аутстаффинга? Аутстаффинг отвечает за выполнение поставленных задач; продуктовая команда — за результат и берёт на себя архитектурные и продуктовые решения. Для MVP, где половина ценности в правильных решениях, это принципиальная разница.
Как проверить, что код будет писать сеньор, а не джун? Спрашивайте прямо, кто именно в команде, и просите познакомиться с теми, кто будет работать, а не с теми, кто продаёт. Уточняйте, сколько времени сеньоры реально проведут в проекте, и фиксируйте состав команды в приложении к договору.
Что должно остаться у клиента после завершения проекта? Как минимум: исключительные права на код, репозиторий в вашей организации, базовая техническая документация и ADR, доступы к инфраструктуре, понятный порядок передачи. Всё остальное — производное от этого минимума.
Это редакционный материал по выбору подрядчика, а не юридическая консультация. Вопросы прав на код, договорных формулировок и соответствия 152-ФЗ сверяйте с квалифицированным юристом.