Сколько стоит разработка приложения: из чего складывается смета

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

Стартовые цены ISKAR и границы предложений

Таблица не является конструктором, где нужно сложить все строки. Например, Flutter и React Native не оплачиваются одновременно для одного и того же решения. Наличие интеграции внутри комплекса и объём серверной части фиксируют в индивидуальном предложении. Актуальные условия — на странице цен на разработку приложений.

Из каких частей собирается смета

• Проектирование: роли, действия пользователя, переходы, ошибки и критерии готовности.
• Дизайн: основные состояния, пустые списки, загрузка, ошибки и доступность.
• Клиентская разработка: экраны, навигация, локальные данные и платформенные функции.
• Сервер: API, права, бизнес-правила, журналирование и окружения.
• Интеграции: каталог, 1С, CRM, оплата, доставка и уведомления.
• Приёмка и выпуск: устройства, сборки, материалы для распространения и передача доступов.

Платформенные модули React Native — пример работы, которую нельзя оценить только количеством страниц. Необходимость такого компонента выясняют до обещания полной общей кодовой базы.

Учебный пример: одинаковые экраны, разная работа

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

Сначала составьте таблицу «сценарий → источник данных → результат → исключение». Для повторного заказа исключением будет снятый с продажи товар, для оплаты — подтверждение после закрытия приложения. Это учебное сравнение сложности, не пример выполненного проекта и не обещание фиксированного количества функций по стартовой цене.

Что часто не входит в первоначальную цифру

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

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

Как сравнить две сметы

1. Выравняйте перечень платформ и сценариев.
2. Проверьте, кто создаёт API и приводит данные в порядок.
3. Сверьте обработку ошибок, повторных действий и ограничений доступа.
4. Уточните тестовые устройства и передаваемые материалы.
5. Разделите запуск, сторонние платежи и последующее сопровождение.

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

Что зафиксировать до согласования бюджета

Как описать строку сметы для приёмки

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

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

Как учитывать изменения после согласования

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

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

Как подготовить данные без передачи секретов

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

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

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