При выборе агентства для разработки MVP решающим критерием служит не стек технологий и не яркость портфолио, а то, спрашивает ли агентство на первой встрече: «На какой вопрос должен ответить этот MVP?». Надёжное агентство ещё до подписания договора чётко отвечает, какую гипотезу мы проверяем, что остаётся за рамками проекта, кому принадлежит код, как будет измеряться валидация и что происходит после запуска. Девять вопросов и таблица тревожных сигналов ниже помогут сравнить ответы разных команд.
Эта статья посвящена только выбору подрядчика. Если вам нужно разобраться, что такое MVP, какие бывают его виды и откуда взялась сама идея, загляните в наше руководство по разработке MVP.
Какие 9 вопросов задать агентству по разработке MVP?
Цель этих вопросов не в том, чтобы устроить агентству экзамен, а в том, чтобы увидеть, как оно на самом деле работает. Важно не только содержание ответа, но и его форма: конкретный пример, письменный документ или процесс, который команда может описать по шагам, говорят намного больше, чем общие обещания.
1. Как вы формулируете гипотезу, которую мы будем проверять?
MVP должен начинаться с допущения, которое нужно подтвердить, а не со списка функций. Хорошее агентство вместе с вами записывает то допущение, при ошибочности которого всё остальное теряет смысл. Если команда сразу переходит к макетам экранов или оценке функций, на выходе, скорее всего, получится не MVP, а недоделанный продукт.
2. Что останется за рамками проекта и кто будет защищать этот список?
В любом MVP есть два списка: что делаем и чего не делаем. Сложнее всего удержать второй. Спросите, что агентство сознательно исключило в одном из прошлых проектов и как объяснило это клиенту. Команда, которая на любую просьбу отвечает «конечно, добавим», удобна в моменте, но именно здесь теряется контроль над сроками и бюджетом.
3. Кому будут принадлежать исходный код, инфраструктурные аккаунты и домен?
Ответ должен быть коротким: вам. Код хранится в репозитории на вашем аккаунте, облачные аккаунты и аккаунты в магазинах приложений оформлены на вашу компанию, а передача интеллектуальной собственности прописана в договоре. Агентство, которое готово «передать» код только в конце проекта или настаивает на размещении всего на своих аккаунтах, делает вас зависимым от себя.
4. Как мы будем измерять валидацию?
До начала разработки нужно зафиксировать три вещи: проверяемое допущение, метрику, которая его измеряет, и порог, при котором ответ считается положительным. Если порог не задан заранее, любой результат потом можно истолковать в свою пользу. Уточните также, будет ли аналитика событий (event tracking) встроена в первый релиз: данные первых недель, пропущенные без неё, уже не вернуть.
5. Как часто я буду видеть работающий продукт?
Доказательство прогресса не скриншот и не презентация, а работающее ПО по реальному адресу. Разумно ожидать коротких спринтов, демонстрации в конце каждого из них и тестовой среды (staging или pre-prod), к которой у вас есть доступ. MVP, который сдают одним куском после нескольких месяцев «работы в фоне», слишком поздно показывает, что команда шла не туда.
6. Что происходит, когда меняется объём работ?
Объём MVP неизбежно меняется, потому что по мере обучения смещаются приоритеты. Важно, как этим управляют. Хороший ответ звучит так: новая задача попадает в приоритизацию следующего спринта, мы вместе решаем, что убрать взамен, и фиксируем это решение письменно. Обе крайности, «каждое изменение отдельной сметой» и «без проблем, впишем», требуют осторожности.
7. Как вы документируете технический долг?
Осознанные упрощения ради скорости естественны для MVP. Проблема не в них, а в том, что они нигде не записаны. Спросите, передаёт ли агентство в конце проекта письменную оценку технического долга, где отделено то, что нужно исправить до роста, от того, с чем можно долго жить. Этот документ станет основой для следующей команды или технической проверки со стороны инвестора.
8. Масштабируется ли MVP или его придётся переписывать?
Честный ответ обычно начинается со слов «зависит от ситуации» и продолжается аргументами. Проектировать MVP под миллионы пользователей с первого дня означает терять время, а вкладываться в код, который целиком пойдёт в корзину, означает терять деньги. Разумный подход: аккуратно принять решения, которые дорого менять потом (модель данных, аутентификация, платежи), и во всём остальном выбирать простоту. Попросите агентство объяснить, какие части задуманы надолго, а какие временно.
9. Что происходит после запуска MVP?
Ценность MVP проявляется в данных, собранных после запуска. Должно быть понятно, сколько длится поддержка после релиза, как обрабатываются ошибки, как планируется следующая итерация и как при желании передать проект другой команде. Агентство, для которого день запуска означает конец проекта, по сути предлагает вам половину работы.
Как отличить хороший ответ от тревожного сигнала?
Таблицу ниже удобно держать перед глазами во время созвонов с агентствами. Один тревожный сигнал не всегда повод отказаться, но если у одной команды их несколько, стоит остановиться и подумать.
| Вопрос | Хороший ответ | Тревожный сигнал |
|---|---|---|
| Гипотеза | Допущение, метрика и порог фиксируются письменно и совместно | Работа начинается сразу со списка функций и макетов |
| Рамки проекта | Письменный список того, что не делаем, с обоснованием | На любую просьбу отвечают «добавим» |
| Владение кодом | Репозиторий и аккаунты на клиенте с первого дня, передача прав в договоре | Код отдают в конце, аккаунты остаются у агентства |
| Измерение валидации | Аналитика событий встроена в первый релиз | «Сначала запустимся, об измерениях подумаем потом» |
| Прозрачность | Короткие спринты, доступная тестовая среда, регулярные демо | Одна сдача через несколько месяцев |
| Изменение объёма | При добавлении нового вместе решают, что убрать | Изменения молча впихивают или каждое превращается в торг |
| Технический долг | Письменная передача технического долга в конце проекта | «У нас в коде технического долга не бывает» |
| Масштабирование | Постоянные и временные части разделены с объяснением | Категоричность: «масштабируется бесконечно» или «всё равно выбросим» |
| После MVP | Понятны поддержка, итерации и варианты передачи | День запуска считается концом проекта |
Как распознать надёжное агентство для разработки MVP?
Помимо ответов на вопросы, есть признаки, которые можно проверить со стороны:
- Проверяемые работы: проекты с названиями, которые работают и доступны для изучения. По возможности попросите короткий разговор с прошлым клиентом.
- Умение сказать «нет»: команда, которая может объяснить, когда MVP не подходит, и открыто говорит о проектах, от которых отказывается.
- Письменный процесс: конкретные документы, например итог этапа исследования, отчёты по спринтам, документ о техническом долге. Попросите показать образец.
- Инженерные практики: code review, автоматизированный конвейер CI/CD и отдельная тестовая среда. Без них частые и безопасные релизы затруднены.
- Осторожность со сроками и ценой: жёсткая дата или фиксированная цена до этапа исследования может означать, что объём не понят, или что риск позже переложат на вас.
Агентство, фрилансер или своя команда для MVP?
У каждого варианта есть ситуации, в которых он оправдан. Выбор зависит от технической экспертизы внутри компании, количества направлений, которые требует продукт, и того, как быстро вы планируете расти после MVP.
| Критерий | Агентство | Фрилансер | Своя команда |
|---|---|---|---|
| Скорость старта | Обычно высокая, команда уже собрана | Высокая, но всё держится на одном человеке | Низкая, нужен найм |
| Набор компетенций | Продукт, дизайн, бэкенд, мобильная разработка и DevOps вместе | Обычно одна-две области | Ограничен теми, кого вы наняли |
| Риск потери преемственности | Низкий, в команде есть взаимозаменяемость | Высокий, знания уходят вместе с человеком | Средний, возможна зависимость от ключевого сотрудника |
| Знания о продукте внутри компании | Через документацию и процесс передачи | Часто остаются в голове одного человека | Остаются в компании естественным образом |
| Структура затрат | По спринтам или по проекту, гибко | Почасово или за задачу | Фиксированные зарплаты плюс расходы на найм |
| Нагрузка на вас по управлению | Управление проектом на стороне агентства | В основном на вас | Полностью на вас |
| Когда подходит | Стартапу, которому нужно несколько направлений и быстрая валидация | Узкому эксперименту на одной технологии | Компании с техническим сооснователем, которая строит продуктовую команду надолго |
Если у вас нет технического сооснователя, при любом варианте понадобится человек, который оценит архитектурные решения подрядчика в ваших интересах. Как закрыть этот пробел без найма CTO на полный день, мы рассказали в статье что такое CTO as a Service и кому он нужен.
Как обычно выглядит работа над MVP?
Названия этапов у агентств разные, но здоровый проект MVP обычно проходит четыре фазы. Их длительность зависит от сложности продукта, интеграций и того, как быстро вы принимаете решения, поэтому к жёстким срокам, обещанным до исследования, стоит относиться осторожно.
- Исследование (discovery): фиксируются гипотеза, целевой пользователь, метрика валидации и порог. Утверждаются списки «делаем» и «не делаем», выявляются технические риски и архитектурные решения. Результат этапа должен быть документом, а не впечатлением.
- Разработка по спринтам: работающее ПО создаётся короткими циклами, каждый спринт завершается демонстрацией в реальной среде, приоритеты обновляются вместе с вами.
- Запуск: продукт выходит к реальным пользователям. К этому моменту должны быть готовы публикация в магазинах приложений, платежи, мониторинг ошибок и аналитика событий.
- Цикл обучения: собранные данные сравниваются с заранее заданным порогом. Итог служит основой для решения: продолжать, менять направление или остановиться. Документ о техническом долге показывает, во что обойдётся следующий шаг по трудозатратам.
Как быть с no-code и прототипами, созданными с помощью ИИ?
Сегодня многие основатели приходят к агентству не с чистого листа, а с работающим прототипом, собранным в Lovable, Cursor, Replit или на no-code платформе. Это неплохой старт: прототип делает первую версию гипотезы осязаемой и ускоряет разговор о рамках проекта. Но работающие экраны ещё не означают готовность к реальным пользователям: авторизация, защита данных, платёжная интеграция и поведение под нагрузкой обычно остаются недоработанными.
В такой ситуации спросите агентство: «Вы прочитаете существующий код, прежде чем что-то обещать?». Хорошая команда сначала отделит то, что действительно работает, от того, что работает случайно, а затем с обоснованием скажет, продолжать ли или переписать отдельные части. Как мы проводим такой переход, описано на странице услуги Vibe-Code to Production, а первичную проверку можно сделать самостоятельно по нашему чек-листу безопасности для vibe-code.
Как мы подходим к MVP в Detartech?
В Detartech мы определяем MVP одной фразой: MVP не уменьшенный продукт, а ответ на вопрос. Поэтому мы начинаем не со списка функций, а с проектирования валидации: письменно фиксируем, какое допущение, какой метрикой и относительно какого порога будем проверять.
- Работаем двухнедельными спринтами и показываем прогресс в виде работающего ПО в pre-prod среде, на протяжении всего проекта поддерживая постоянный контакт с клиентом.
- Код проходит peer review, автоматизированный CI/CD настроен с первого дня, поэтому релиз перестаёт быть событием.
- В конце проекта передаём письменную оценку технического долга, где отделено то, что нужно изменить до роста, от того, что может остаться как есть.
- 30 дней поддержки после запуска входят в работу.
Подробности об услуге собраны на странице разработка MVP, а работающие примеры наших проектов на странице истории успеха.
Если у вас есть идея MVP или готовый прототип, задайте эти девять вопросов и нам. Для бесплатной консультации заполните форму быстрого запроса, мы отвечаем в течение 24 часов.
Часто задаваемые вопросы
Достаточно ли сравнить коммерческие предложения при выборе агентства для MVP?
Нет, потому что предложения обычно оценивают разный объём работ. Сначала сравните, как каждое агентство формулирует гипотезу, что оставляет за рамками и как измеряет валидацию. Сравнение цен имеет смысл только тогда, когда объёмы отвечают на один и тот же вопрос.
Кому должен принадлежать исходный код MVP?
Исходный код, инфраструктурные аккаунты и домен с самого начала должны принадлежать стартапу. Репозиторий создаётся на вашем аккаунте, а передача интеллектуальной собственности прописывается в договоре. Это защищает вас, если позже вы смените подрядчика или перейдёте к собственной команде.
Как работать с агентством, если у меня нет технического сооснователя?
Полезно привлечь независимого технического эксперта, который будет оценивать архитектурные и технологические решения агентства в ваших интересах. Это может быть технический консультант на частичной занятости или формат CTO as a Service. Также просите письменно фиксировать каждое важное решение вместе с обоснованием.
Обязательно ли MVP придётся переписывать с нуля?
Не обязательно, всё зависит от того, как он был построен. Если базовые решения (модель данных, аутентификация, платежи) приняты аккуратно, продукт обычно растёт за счёт постепенных улучшений. Письменный документ о техническом долге показывает, что и когда нужно менять.
Может ли агентство взять в работу прототип, сделанный в Lovable или Cursor?
Да, в большинстве случаев может. Правильный первый шаг: агентство изучает существующий код до каких-либо обещаний и составляет список пробелов в безопасности, интеграциях и устойчивости. После этого с обоснованием решается, какие части сохранить, а какие переписать.
Что подготовить к первой встрече с агентством по разработке MVP?
Достаточно нескольких предложений о проблеме, которую вы решаете, о целевом пользователе и о самом критичном допущении, которое нужно проверить. Встречу сделают продуктивнее примеры конкурентов, существующий прототип или макеты и дата, к которой вам нужно принять решение. Список функций готовить не обязательно, его разумнее составить вместе на этапе исследования.
