КП на разработку мобильного приложения: что включить и как оценить

Клиент хочет «приложение как у крупного сервиса доставки, но попроще». Вы считаете экраны, получаете приличную сумму, отправляете КП. А потом выясняется, что клиент рассчитывал на обе платформы, админку для операторов, push-уведомления и публикацию в магазинах приложений — и всё это, по его мнению, входило в цену. Коммерческое предложение на разработку приложения чаще всего проваливается не из-за суммы, а из-за того, что стороны по-разному понимают, что такое «приложение».

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

Из чего состоит мобильное приложение на самом деле

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

• Клиентская часть — экраны и логика на смартфоне: под iOS, под Android или кроссплатформенно.
• Серверная часть — API, база данных, авторизация, бизнес-логика, хранение файлов.
• Панель администратора — то, через что сотрудники клиента управляют контентом, заказами, пользователями.
• Инфраструктура и публикация — серверы, сборки, аккаунты разработчика, прохождение модерации магазинов приложений, push-уведомления, аналитика.

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

Вопросы, без которых оценка приложения бессмысленна

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

1. Платформы. Только Android, только iOS, обе? Нативная разработка или кроссплатформенная?
2. Есть ли готовый сервер. Иногда у клиента уже есть сайт или учётная система с API — тогда бэкенд сокращается до доработок.
3. Офлайн-режим. Должно ли приложение работать без сети и синхронизироваться потом? Это заметно усложняет логику.
4. Функции устройства: камера, геолокация, карты, биометрия, платежи внутри приложения.
5. Роли пользователей. Покупатель и курьер — это часто два разных приложения, а не одно.
6. Кто публикует. Чьи аккаунты разработчика, кто отвечает за прохождение модерации.
7. Что после запуска. Обновления под новые версии операционных систем, исправление ошибок, развитие.

Как оценить приложение: от экранов к часам

Самый понятный для клиента способ — оценка от экранов и сценариев. Вы составляете список экранов, группируете их по сценариям (регистрация, каталог, оформление заказа, профиль) и для каждого сценария оцениваете дизайн, клиентскую разработку и серверную логику отдельно.

Такой подход хорош тем, что клиент видит прямую связь: убираем сценарий — уходит конкретное количество часов. Это гораздо понятнее, чем «разработка приложения — 2 000 000 ₽».

Ниже — условный пример оценки приложения для записи в сеть салонов: одна платформа кроссплатформенно, 14 экранов, своя серверная часть и простая админка.

Обратите внимание на ширину диапазонов. У тестирования и отладки разброс больше всего — потому что количество ошибок на разных устройствах и замечаний модерации заранее не знает никто. Честно показать это в КП лучше, чем потом объяснять перерасход. Подробнее о том, как считать часы и ставки, — в статье про оценку трудозатрат в часах.

MVP и очереди: как снизить порог входа

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

• Первая очередь (MVP) — минимальный набор сценариев, с которым приложение уже приносит пользу: например, только запись и уведомления.
• Вторая очередь — программа лояльности, оплата в приложении, отзывы.
• Третья очередь — всё, что клиент хотел бы «когда-нибудь».

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

Плохо: «Разработка мобильного приложения под ключ — по договорённости».

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

Что ещё обязательно написать в КП на приложение

Есть несколько пунктов, которые в веб-проектах можно опустить, а в мобильных — нельзя:

• Сроки модерации магазинов приложений. Они не зависят от вас, поэтому в сроках проекта стоит заложить запас и написать об этом.
• Поддерживаемые версии систем и устройства. «Android начиная с такой-то версии, смартфоны, без планшетов» — одна строка, которая снимает много вопросов.
• Сторонние сервисы и их стоимость. Аккаунты разработчика, сервисы push-уведомлений, карты, SMS для авторизации — отдельными строками, даже если цифры приблизительные.
• Права на код и аккаунты. На кого публикуется приложение и кому передаётся исходный код.
• Поддержка после релиза. Новые версии операционных систем выходят регулярно, и приложение без поддержки со временем перестаёт работать корректно. Предложите поддержку отдельным блоком.

Нативная или кроссплатформенная разработка: как показать выбор в КП

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

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

Плохо: «Разработка на Flutter».

Хорошо: «Одно приложение для Android и iOS из общей кодовой базы: быстрее запуск и дешевле последующие обновления».

Чек-лист КП на разработку приложения

• Указаны платформы и подход: нативно или кроссплатформенно.
• Клиентская часть, сервер, админка и публикация — отдельными блоками.
• Оценка привязана к экранам и сценариям, а не только к общей сумме.
• Тестирование и отладка оценены с широким диапазоном.
• Проект разбит на очереди, первая очередь понятна сама по себе.
• Сторонние сервисы и их ориентировочная стоимость вынесены отдельно.
• Есть пункт о сроках модерации, правах на код и поддержке.

Как kptp.ru решает эту проблему

Мобильный проект состоит из многих блоков с разной степенью неопределённости. В kptp.ru их удобно показать клиенту так, чтобы он видел и структуру, и разброс.

• Этапы и строки с часами «от – до» — у каждого блока свой диапазон: узкий для дизайна, широкий для отладки. Итог показывается диапазоном или фиксированной суммой по вашей формуле.
• Подзаголовок строки — роль исполнителя: мобильный разработчик, бэкенд-разработчик, дизайнер интерфейсов. Клиент видит, что над проектом работает команда.
• Режимы «Услуги» и «Товары» — работы в часах и разовые покупки вроде аккаунтов разработчика и платных сервисов в одном КП.
• Сроки из темпа исполнителя — дни на этап считаются автоматически, можно вручную задать дату завершения с учётом модерации.
• Несколько опубликованных версий КП в проекте — первую очередь и полную версию можно отправить одной ссылкой, клиент переключается между ними выпадающим списком.

Все функции доступны на пробном периоде — 7 дней бесплатно.