Как нанять разработчика для MVP и не переплатить

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

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

Что подготовить, прежде чем нанять разработчика для MVP

Чем меньше разработчику придётся выяснять, тем меньше ты заплатишь за выяснение. Собери:

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

Всё это помещается на одну-две страницы. Документ, который можно переслать трём кандидатам, сразу делает их оценки сравнимыми.

Как описать объём работ

Плохая задача — «доделать приложение». Хорошая — описанный результат, который можно проверить без разработчика:

человек регистрируется, оплачивает подписку и получает доступ;
приложение опубликовано в App Store и Google Play;
ошибки на сервере приходят уведомлением, а не от пользователей.

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

Сначала платный аудит

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

Лучше начать с небольшого платного аудита с фиксированным объёмом: разработчик читает код, проверяет безопасность и инфраструктуру и отдаёт письменный результат. В нём должно быть:

что в проекте опасно прямо сейчас;
что можно оставить, а что придётся переделать, и почему;
оценка работ по этапам из твоего списка.

Документ остаётся у тебя, даже если дальше ты пойдёшь к другому подрядчику. А заодно ты увидишь, как человек объясняет решения, — это и есть пробный проект.

Тревожные сигналы

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

Один сигнал — повод уточнить. Три — повод искать дальше.

Фиксированная цена или оплата по времени

Обе модели честные, когда применяются по назначению.

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

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

Частая рабочая схема — комбинация: фиксированный аудит, потом этапы фиксированной длины с понятной целью и потолком.

Как работать после найма

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

Коротко

Подготовь доступы на своё имя, честный список проблем и главные сценарии.
Описывай результат, который можно проверить без разработчика, и дели работу на этапы.
Начни с платного аудита: это и оценка, и пробный проект.
Фикс — для задач с понятной границей, оплата по времени — для неясных и с потолком.
Код и доступы остаются у тебя с первого дня.

SUBXCAT как раз доводит вайбкод-проекты до запуска и обычно начинает с такого аудита.