Как нанять React Native-разработчика под MVP: чек-лист, вопросы и красные флаги

Найм под MVP решает две вещи: как быстро вы дойдёте до живых пользователей и сколько потратите потом на переделки. Ошибка тут стоит не только денег — она съедает запас времени и momentum, а иногда и всю идею выпустить продукт, пока хватает терпения на процесс.

Почему MVP меняет портрет разработчика

MVP — не уменьшенная копия финального продукта. Это другой тип сборки. Вы оптимизируете скорость до тестируемого продукта и возможность быстро развернуться, а не обработку десяти миллионов пользователей и всех краевых случаев зрелого продукта.

Отсюда другое определение слова «хороший». Нужен человек, который умеет принимать резкие решения по скоупу. Тот, кто переусложнит экран логина, потому что так технически правильнее, заберёт у вас две недели на то, что вообще не влияет на проверку гипотезы. Сильный MVP-разработчик имеет мнение о том, что выкинуть, а не только о том, что построить.

Фрилансер, агентство или найм в штат

На стадии MVP одиночный senior-фрилансер или очень маленькая команда почти всегда выгоднее, чем полноценное агентство или преждевременный найм в штат. Нужен человек, который владеет всей сборкой, принимает решения без прослойки аккаунт-менеджеров и стоит достаточно дешёво, чтобы разворот не утопил бюджет.

Что реально смотреть в кандидате

Резюме и количество лет опыта не говорят почти ничего о том, доведёт ли этот человек ваш MVP до стора. Проверять стоит вот что.

• Опубликованные приложения, а не примеры кода. Просите ссылки в App Store и Google Play на продакшн-приложения, которые человек собирал, а не GitHub с пет-проектами. Скачайте одно. Откройте. Попользуйтесь. Тот, кто выпустил несколько реальных приложений, уже совершил и разобрал ошибки, которые вашему MVP иначе пришлось бы преподать вам.
• Готовность работать с бэкендом. Большинству MVP нужен человек, умеющий рассуждать про API, базу и модель данных, даже если он не специалист во всём сразу. Чистый фронтендер отдаст оболочку интерфейса и оставит самую сложную часть — слой данных — кому-то другому.
• Вопросы про ваш бизнес. Разработчик, которого стоит нанимать, спросит, что именно вы собираетесь доказать этим MVP, и поспорит с фичами, которые этой цели не служат. Если в первом созвоне все вопросы чисто технические, он соберёт ровно то, что вы попросили, — включая то, чего просить не стоило.
• Прямой ответ про сроки и деньги. Реальный MVP — это недели работы, не дни. Уклончиво-оптимистичная оценка тревожит сильнее, чем честная и чуть более длинная.

Четыре вопроса до подписания

1. «Покажете приложение, которое вы довели до конца сами, а не просто участвовали в нём?» Важно, чтобы человек владел сборкой от архитектуры до публикации, а не чинил баги в чужом коде.
2. «Что вы вырежете из моего скоупа, чтобы уложиться в сроки MVP?» Ответ показывает, мыслит человек компромиссами или тикетами.
3. «Как вы реагируете на изменения скоупа посреди сборки?» MVP меняется по ходу, пока вы узнаёте новое о пользователях. Разработчик должен этого ожидать, а не считать каждый новый запрос боем.
4. «Кто отвечает за бэкенд и деплой?» Получите явный ответ до старта, а не после релиза, когда ни у кого нет ни серверных доступов, ни доступа к аккаунту разработчика в сторе.

Красные флаги

• Портфолио из почти одинаковых шаблонных приложений. Обычно это признак дешёвого конвейера, заточенного под объём, а не под вашу задачу.
• Ни одного живого приложения в сторах. Если всё — демки, прототипы в Figma или неопубликованные сборки, вы пока не знаете, умеет ли человек проходить ревью App Store. А это отдельный навык.
• Смета без разговора про скоуп. Настоящая оценка MVP невозможна без понимания задачи: ровная цифра до обсуждения — заглушка.
• Уклонение от разговора об архитектуре. Спросите, как он видит структуру бэкенда и ядро модели данных. Расплывчатый ответ обычно означает, что об этом ещё не думали. Думать придётся вам, посреди сборки.

Сколько это стоит

Цифры сильно зависят от скоупа, но настоящий MVP — несколько ключевых экранов, авторизация, работающий бэкенд и реальная модель данных — редко укладывается в «пару сотен долларов» или в нижнюю границу пятизначных сумм. Тот, кто называет цену сильно ниже рынка, либо недооценил объём, либо планирует срезать углы на бэкенде, либо добьёт смету дополнительными запросами по ходу проекта. Логика здесь та же, что и в любой заказной разработке: дешевле всего выходит работа, которую не придётся переделывать.

Что подготовить до разговора с разработчиком

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

Пример

WealthyGen и RxCalendar начинали как узкие сборки на React Native: плотный набор ключевых функций, реальный бэкенд с первого дня, короткий путь до App Store. Ни одному из них не понадобилась большая команда или длинный runway — нужен был один разработчик, который владеет архитектурой от и до и принимает решения о том, что не входит в первую версию.

Сроки и платформа

Фокусный MVP обычно занимает от 6 до 12 недель у одного опытного разработчика — разброс зависит от объёма бэкенда и интеграций. Обещание собрать полный MVP за неделю-две означает, что скоуп урезан сильнее, чем вы себе представляете.

Нативный разработчик вместо React Native нужен почти никогда. Для подавляющего большинства MVP кроссплатформенный стек доводит до App Store и Google Play за меньшие деньги и в более короткий срок.

Правильный найм под MVP — это человек с опубликованными приложениями, который берёт на себя архитектуру целиком и говорит, что выкинуть, вместо того чтобы собирать весь список из вашей таблицы. Это важнее лет опыта, размера портфолио и самой низкой сметы в почте. Сделайте этот выбор верно — и сроки, деньги и коммуникация обычно складываются сами.