Сколько стоит разработка MVP и из чего складывается цена

Что такое MVP и чем он отличается от полной версии

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

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

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

Из чего складывается цена

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

Платежи и неудачные списания

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

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

Письма и доставляемость

Письмо с приглашением, которое попало в спам, для пользователя значит, что продукт не работает. Чтобы письма доходили, домен отправителя настраивают так, чтобы почтовые сервисы могли проверить, что письмо действительно ваше. За это отвечают записи SPF, DKIM и DMARC.

Это не требует много времени, но про это часто забывают, а обнаруживают проблему уже после запуска. Спросите, будет ли это проверено до сдачи этапа.

AI-часть и её стоимость в эксплуатации

У AI-сервиса есть вторая цена, о которой не говорят при заказе: каждый запрос к модели стоит денег каждый раз, пока продукт работает. Разработка оплачивается один раз, а расходы на модель идут постоянно и растут вместе с пользователями.

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

Актуальные тарифы на модели публикует сам провайдер на своей странице цен, и они меняются. Закладывать в бюджет стоит цифры оттуда на день расчёта, а не цифры из чужой статьи.

Как резать на этапы

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

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

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

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

Как принимать работу

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

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

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

На чьих аккаунтах должен жить продукт

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

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

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

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

Типичные ошибки основателя

• Хотеть всё сразу. Список функций на сорок пунктов превращается в проект на много месяцев, где проверка идеи откладывается.
• Не описать платежи и роли. Именно они потом дают больше всего неожиданных доплат.
• Принимать работу по ощущению. Без чек-листа любой спор о том, готово или нет, решается голосом, а не фактами.
• Платить за всё вперёд. Оплата по этапам защищает обе стороны.
• Оставить аккаунты исполнителю, потому что так быстрее начать. Потом это становится самой дорогой частью.
• Не считать расходы на эксплуатацию: сервер, письма, модель. Разработка это только часть бюджета.
• Просить точную цену без описания. Честный исполнитель назовёт её после разбора, а не по одной фразе.

Как описать продукт в пяти строках

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

1. Кто пользователь: одной фразой, кому нужен сервис и в какой ситуации.
2. Что делает сервис: главное действие, которое пользователь совершает, и результат, который он получает.
3. Роли: какие типы пользователей есть, например обычный пользователь, администратор, владелец организации, и чем они отличаются.
4. Деньги: берёте ли вы оплату, подписка это или разовые платежи, какие тарифы и что происходит при неудачном списании.
5. Макеты и срок: есть ли готовый дизайн и к какой дате нужен первый показ.

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

Что получится на выходе разбора

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

Заказать разработку MVP

Я делаю MVP AI-сервисов и SaaS под ключ: ТЗ, этапы через безопасную сделку, приёмка по вашему чек-листу, аккаунты на вас, код в вашем репозитории. Цена от 80 000 ₽ за MVP, точную цену и срок каждого этапа называю после ТЗ, до начала работы. Пришлите пять строк о продукте, за день разберу, назову этапы и цену. Подробности на странице mikhailai.ru/mvp/.