Стоимость разработки ПО

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

Название продукта мало говорит о его сложности. В одном личном кабинете клиент смотрит заказы и скачивает документы. В другом несколько подразделений согласуют заявки, работают с разными правами и обмениваются данными с учётной системой. Интерфейс может выглядеть похоже, но объём работы будет разным. Опишите путь пользователя от начала до результата: кто входит в систему, что видит, какие действия совершает и что происходит при ошибке. Отдельно перечислите роли сотрудников и административные задачи. Создание пользователей, исправление данных и выгрузка отчётов тоже входят в продукт. Затем выберите платформы. Для работы в браузере можно рассмотреть веб-приложение. Для сценариев со смартфоном — мобильное приложение. Если нужны локальные устройства, специальная периферия или работа на компьютере без сети, обсудите прикладную систему.

Аналитика. Описываем роли, основные сценарии, состав первой версии и ограничения. Разбираем интеграции и формулируем критерии приёмки. Проектирование и дизайн. Готовим структуру, прототипы и экраны. Проверяем состояния загрузки, пустые списки, ошибки и действия с данными. Согласованные компоненты помогают сохранять единый интерфейс. Разработка. Создаём клиентскую и серверную части, административные инструменты и обмен с внешними системами. Объём каждой части фиксируем в задании. Тестирование. Проверяем согласованные сценарии, права доступа, сохранение данных и работу на выбранных устройствах. Исправляем найденные ошибки и повторяем проверки. Выпуск и передача. Настраиваем окружение, готовим сборки, документацию и доступы. Заранее определяем, кто отвечает за дальнейшую поддержку. У каждого этапа в предложении должны быть результат, стоимость, срок и зависимости. Условия оплаты обсуждаются отдельно. Для приёмки важен перечень готовых работ и проверок.

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

Выделите один законченный сценарий, который продукт должен поддерживать на запуске. Например, клиент выбирает услугу, отправляет заявку и получает подтверждение, а сотрудник видит её и продолжает работу. Для первой версии важно довести этот путь целиком. Редкие отчёты, дополнительные роли и второстепенные интеграции можно вынести в следующий этап. При этом проверка прав, сохранность данных и обработка ошибок остаются частью первого релиза. В Brawus ориентир для полноценного мобильного приложения под ключ начинается от 800 тыс. ₽. Это стартовый бюджет для обсуждения подходящего объёма; стоимость конкретного продукта определяем после разбора задачи. Калькулятор приложения помогает собрать исходные параметры для разговора.

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

Сначала приведите предложения к одинаковому составу. Проверьте, включены ли аналитика, дизайн, сервер, панель администратора, интеграции, тестирование и выпуск. Уточните, кто предоставляет тексты, изображения и доступы. Посмотрите на результаты этапов. Формулировку «разработка приложения» полезно раскрыть до функций, платформ и критериев готовности. Попросите назвать ограничения: поддерживаемые устройства, объём данных, внешние системы и сценарии работы без сети. Отдельно обсудите передачу исходников, сборок, документации и прав на аккаунты. Изучите кейсы команды и уточните её роль в проектах. Опыт с похожими данными и интеграциями помогает оценить соответствие вашей задаче.

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

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