Коммерческое предложение на разработку мобильного приложения: что писать и как считать
Мобильное приложение почти никогда не заказывают целиком «под ключ» одним решением: заказчик приходит с идеей и списком желаемых функций, а объём работы определяется числом экранов, платформами и тем, что уже есть на стороне бизнеса — сайт, база пользователей, серверная часть. Поэтому предложение начинается не с цены, а с фиксации границ: какие платформы охвачены, какие устройства и версии операционных систем поддерживаются, какие функции входят в первую версию, а какие вынесены в следующие релизы. Без этого любая сумма выглядит произвольной, и разговор сводится к торгу.
Вторая особенность — то, что приложение не заканчивается сдачей кода. Его нужно опубликовать в магазинах, а публикация зависит от аккаунтов разработчика, правил модерации и требований к содержимому, и часть из этого находится вне контроля команды. Дальше идут обновления операционных систем, новые размеры экранов и правки, которых требует модерация при следующих релизах. В предложении стоит заранее разделить разработку версии, публикацию и поддержку после запуска — это три разные зоны ответственности с разными сроками и разным порядком оплаты.
Из каких блоков собрать предложение
Опишите, что приложение должно делать для пользователя и какой сценарий считается основным. Перечислите функции, входящие в первый релиз, и отдельно те, что сознательно перенесены дальше. Такой список закрывает большую часть будущих споров об объёме.
Укажите, разрабатывается ли приложение для iOS, Android или обеих платформ, и по какому пути — нативно на каждую или на общей кодовой базе. Назовите минимальные версии операционных систем, поддержку планшетов и ориентацию экрана. Это напрямую влияет на объём вёрстки и тестирования.
Дайте перечень экранов с коротким описанием: авторизация, каталог, карточка, корзина или заявка, профиль, настройки, служебные состояния. Отдельно отметьте экраны с нестандартной логикой — карты, камера, сканирование, офлайн-режим. Именно по этому списку считается макет и разработка.
Зафиксируйте, разрабатывается ли backend с нуля или приложение работает с существующим API заказчика. Перечислите внешние интеграции: платежи, push-уведомления, аналитика, авторизация через сторонние сервисы, карты. Укажите, кто предоставляет доступы и оплачивает сторонние сервисы.
Опишите, на каком наборе устройств проводится проверка, как передаются сборки для приёмки и в каком виде принимаются замечания. Оговорите, что считается дефектом, а что — новым требованием: это разделение определяет, попадает правка в текущий этап или в следующий.
Укажите, что нужно для выпуска: аккаунты разработчика, юридические данные, политика конфиденциальности, описания и скриншоты. Отметьте, что сроки модерации задаёт площадка, а требования к содержимому и функциям могут измениться. Разделите первичную публикацию и последующие обновления.
Разложите стоимость по этапам и ролям, отдельно вынесите вторую платформу и серверную часть. Опишите, как оплачивается сопровождение: обновления под новые версии операционных систем, исправление инцидентов, выпуск новых версий. Укажите, что входит в месяц поддержки, а что считается доработкой.
Что обычно входит в смету
- Проработка требований и сценариев использованиячас
- Проектирование интерфейса и прототипэкран
- Дизайн-макеты под платформуэкран
- Разработка клиентской части приложенияэкран
- Разработка серверной части и методов APIспринт
- Подключение внешнего сервисаинтеграция
- Настройка push-уведомлений и сбора аналитикиэтап
- Тестирование на наборе устройствустройство
Блоки, смета с расчётом и условия уже готовы — останется вписать свои цены. Клиент открывает ссылку в браузере, а вы видите, кто её открыл и докуда дочитал.