Объём первой версии
Количество ролей, экранов, сценариев и бизнес-правил определяет объём продуктовой и технической работы.
Стоимость проекта
Сколько стоит разработка приложения или MVP?
Мы не публикуем условную цену «от». Два проекта с одинаковым названием могут сильно отличаться по сценариям, интеграциям и подготовке к запуску. Сначала определяем границы первой версии, затем оцениваем работу по этапам.
Стоимость по типу продукта
Название продукта — только отправная точка
Оценку определяют действия пользователей, связи с внешними системами и требования к запуску. Ниже — основные факторы стоимости для каждого направления.
Что формирует бюджет
Шесть факторов, которые сильнее всего влияют на оценку
Полезная смета — не догадка, умноженная на ставку. Она связывает цель продукта с конкретными сценариями, техническими решениями и ответственностью за запуск.
Платформы и устройства
Продукт для браузера, мобильное приложение для одной или двух платформ и общая серверная часть требуют разных планов разработки.
Готовность дизайна
Готовые исследования и макеты сокращают подготовку. Если их нет, проектирование сценариев, прототип и дизайн интерфейса входят в объём работ.
Интеграции и данные
Оплаты, карты, CRM, ERP, авторизация, API устройств и перенос данных добавляют задачи разработки и проверки.
Требования к качеству
Безопасность, нагрузка, офлайн-режим, доступность, журналирование действий и сложные права доступа меняют архитектуру и объём тестирования.
Запуск и поддержка
Публикацию в магазинах, настройку инфраструктуры, мониторинг, документацию, гарантийные работы и развитие продукта фиксируем в плане отдельно.
От запроса до сметы
Как мы готовим оценку проекта
После короткого брифа обычно готовим первичную поэтапную оценку за два рабочих дня. Если в продукте есть серьёзные технические неизвестные, обозначаем их до того, как считать цифру обязательством.
- 1
Разбираем ожидаемый результат
Обсуждаем бизнес-цель, аудиторию, готовые материалы, целевые платформы и результат, который должна дать первая версия.
- 2
Определяем первую версию
Описываем основной путь пользователя, отделяем обязательные функции от следующих итераций и фиксируем допущения, влияющие на оценку.
- 3
Разбиваем работу на задачи
Группируем задачи по этапам анализа, дизайна, разработки, тестирования и запуска, показываем зависимости и известные риски.
- 4
Согласуем этапы
До начала разработки фиксируем результаты, точки приёмки, порядок оплаты, сроки и условия передачи прав в смете и договоре.
Вопросы о стоимости
Что спрашивают об оценке и оплате
Точная сумма появляется после понимания объёма работ. Ниже объясняем, что происходит до оценки и как контролируется бюджет после неё.
Почему на сайте нет фиксированного прайса?
Мобильное приложение, веб-продукт или MVP — не стандартный пакет. Роли пользователей, интеграции, готовность дизайна, данные и требования к запуску могут менять объём работы в несколько раз. Поэтапная смета под реальную первую версию полезнее рекламной цены, из которой исключены обязательные задачи.
Можно получить ориентир без готового технического задания?
Да. Для первой оценки не требуется подробное техническое задание. Достаточно короткого брифа о цели, аудитории, платформах, основном сценарии, готовых материалах и интеграциях. На этой основе можно дать предварительный диапазон и перечислить допущения.
Что входит в оценку разработки?
Смету делим на согласованные этапы. В них могут входить анализ продукта, проектирование сценариев и интерфейса, разработка клиентской и серверной частей, интеграции, тестирование, подготовка к запуску и документация. Отдельно показываем, что входит в текущую версию, а что остаётся за её пределами.
Как сократить бюджет первой версии?
Самый безопасный способ — оставить один центральный сценарий, перенести второстепенные роли и автоматизацию, использовать надёжные готовые сервисы там, где это уместно, и не разрабатывать предположительные функции до проверки главной гипотезы.
Как организована оплата?
Работаем по договору и делим проект на этапы с определённым результатом. Оплата привязана к согласованным этапам, поэтому заказчик может на всём протяжении разработки сопоставлять прогресс со сметой.
Кому принадлежит исходный код после оплаты?
Исходный код и проектная документация принадлежат заказчику на условиях, согласованных в договоре. Состав результата и передачу прав фиксируем до начала работ.
Входит ли поддержка после запуска?
Ответственность за запуск и гарантийный период фиксируем в условиях проекта. После него мониторинг, обновление зависимостей, исправления и разработку новых функций можно продолжить в отдельно согласованном формате поддержки.
Нужна оценка именно вашего продукта?
Расскажите о цели, основном пользовательском сценарии и готовых материалах. Определим следующий шаг и список данных для реалистичной сметы.