Калькулятор стоимости разработки приложения: как оценить бюджет

Как работает калькулятор стоимости приложения

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

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

Что должен учитывать расчет

Хорошая предварительная оценка начинается не с количества экранов, а с пользовательского сценария. Кто откроет приложение? Что этот человек должен сделать? Какие данные понадобятся на каждом шаге? Что произойдет, если оплата не пройдет, курьер опоздает или пользователь отменит бронирование?

В расчете важно учесть:

• платформы: iOS, Android, веб-версию или приложение для планшета;
• регистрацию, личный кабинет и разные роли пользователей;
• серверную часть и хранение данных;
• оплату, подписки, возвраты и чеки;
• карты, чат, уведомления и работу без интернета;
• интеграции с CRM, 1С, службами доставки и другими системами;
• админ-панель для сотрудников;
• аналитику, тестирование и публикацию в магазинах приложений.

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

Что меняет объём проекта

Полезная оценка опирается на конкретные действия. Например, «пользователь записывается на услугу» оставляет вопросы: выбирает ли он сотрудника, платит ли заранее, может ли перенести запись сам и что делает администратор, если мастер заболел? Такие ответы важнее количества экранов.

Что быстрее всего увеличивает стоимость

### Несколько ролей

Покупатель, продавец, курьер, оператор и администратор видят разные данные и могут выполнять разные действия. Для каждой роли нужны права доступа, отдельные состояния интерфейса и дополнительные проверки.

### Платежи и подписки

Один экран оплаты скрывает много сценариев: успешный платеж, отказ банка, повторная попытка, возврат, отмену подписки и восстановление покупки. Правила цифровых покупок нужно заранее сверить с требованиями App Store и Google Play.

### Интеграции

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

### Админ-панель

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

### Работа без интернета и синхронизация

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

Как сделать оценку точнее

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

Разделите функции на три группы:

1. Без них первую версию нельзя запускать.
2. Они полезны, но могут появиться после проверки спроса.
3. Решение по ним пока не принято.

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

Как Appfyl готовит оценку

В Appfyl сначала читают отправленный бриф, затем уточняют основной сценарий, состав первой версии, интеграции и возможные технические риски. Среди публичных проектов команды — CakeSchool, AB.Money, My Cake и Padi Pay. Примеры работ собраны в портфолио Appfyl.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Чего бриф не может угадать за вас

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

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

Как читать ответ команды

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

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

Какие примеры помогут уточнить задачу

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

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

Не отправляйте через открытую анкету пароли и персональные данные клиентов. Для первого обсуждения хватит обезличенного примера или изображения без чувствительной информации. Безопасный доступ к системам можно организовать позже. О том, как дальше устроена работа, мы рассказываем в статье об этапах разработки; когда будете готовы, заполните бриф.

Частые вопросы