Главное
Не существует одной надёжной «средней цены по Беларуси» для лендинга, кабинета и операционной платформы одновременно. Сначала зафиксируйте процесс, неизвестные и критерии первой поставки, затем считайте объём по ролям, внешние расходы и объяснимый резерв риска.
Короткий ответ «сайт — от X, система — от Y» удобен для рекламы и почти бесполезен для решения. Два проекта с одинаковыми десятью экранами могут отличаться в цене в несколько раз: один читает данные из готового API, другой должен синхронизироваться с тремя старыми системами, переживать сбои и учитывать разные права сотрудников.
Поэтому честная смета начинается не с количества страниц. Она начинается с рабочих сценариев и неизвестных.
Почему мы не публикуем «среднюю цену по Беларуси»
Мы не располагаем проверенной открытой выборкой сопоставимых белорусских проектов, по которой можно рассчитать полезную среднюю цену. Диапазоны из каталогов часто объединяют небольшие сайты и многолетние платформы. Поэтому мы не выдаём их за стоимость вашего проекта: полезнее разобрать конкретный объём работ и допущения.
Вместо этого полезнее показать, что подрядчик обязан посчитать и как заказчик может проверить логику оценки.
Семь блоков стоимости
1. Discovery и постановка
Кто пользуется системой, какой процесс меняется, что происходит сейчас, где границы первой версии, чем измеряется результат. Если это не выяснить до разработки, работа всё равно состоится — только позже и дороже, в виде переделок.
2. Интерфейсы и роли
Цена зависит не от числа макетов, а от числа разных сценариев и состояний: пустые данные, ошибки, отмена, повтор, ограничения роли, мобильное использование, доступность.
3. Backend и интеграции
API, очереди, фоновые задачи, платежи, CRM, учётные системы, импорт файлов, уведомления. Главные неизвестные — качество внешней документации, тестовый контур, rate limits, нестабильные идентификаторы и ответственность при сбое.
4. Данные и миграция
Схема базы — небольшая часть. Нужно очистить дубли, сопоставить старые справочники, проверить полноту, провести пробную миграцию и иметь rollback.
5. Безопасность и надёжность
Роли, аудит, резервные копии, защита загрузок, secrets, rate limits, мониторинг, recovery. Для AI добавляются eval, ограничения инструментов и контроль данных.
6. QA и приёмка
Тесты happy path не покрывают реальную эксплуатацию. Нужны права, ошибки интеграций, повторные запросы, нагрузка, восстановление и критерии готовности.
7. Запуск и поддержка
CI/CD, инфраструктура, миграции, обучение пользователей, документация, гарантийный период, SLA и развитие. «Код готов» не означает, что команда умеет поддерживать продукт в понедельник утром.
Формула оценки
Рабочая формула выглядит так:
стоимость = объём работ по ролям × согласованные ставки + внешние расходы + резерв на подтверждённые риски
Под объёмом лучше понимать человеко-дни или недели по потокам: продукт/аналитика, дизайн, frontend, backend, QA, DevOps, security. Внешние расходы — облако, лицензии, платные API, оборудование и сторонние специалисты.
Резерв не должен быть случайными 30%. У каждого заметного риска есть причина: неизвестное API, неподготовленные данные, незавершённый дизайн, отсутствие тестовой среды. Его можно уменьшить коротким техническим исследованием до основного контракта.
Как получить диапазон, которому можно верить
Этап 1. Быстрая квалификация
Подрядчик понимает процесс, пользователей, ожидаемый эффект и ограничения. Результат — не цена до копейки, а решение: можно ли оценивать дальше и какие данные нужны.
Этап 2. Ограниченный discovery
Команда разбирает 1–3 главных сценария, интеграции, данные, архитектурные риски и критерии приёмки. При необходимости делает технический spike. На выходе — границы версии, карта неизвестных и диапазон.
Этап 3. План первой поставки
Большой продукт режется на работающие этапы. У каждого есть observable result, приёмка и решение продолжать, изменить объём или остановиться.
Так заказчик платит за уменьшение неопределённости, а не за красивую «фиксированную» цифру с будущими change requests.
Пример, почему одинаковые экраны стоят по-разному
Допустим, нужен кабинет с заявкой, статусом и уведомлением.
Вариант А: один тип пользователя, новая база, готовый email-провайдер, ручная проверка менеджером. Основной объём — интерфейс, API и базовая эксплуатация.
Вариант Б: четыре роли, данные из 1С и CRM, юридически значимые статусы, вложения, журнал всех изменений, SMS, миграция истории и работа при временной недоступности интеграций.
На макете оба проекта выглядят похоже. В архитектуре вариант Б содержит очереди, идемпотентность, reconciliation, сложную модель прав, аудит и миграционный контур. Считать их «по экранам» нельзя.
Что должно быть видно в смете
- Результат этапа, а не только список специалистов.
- Допущения: какие API, данные и люди доступны.
- Что не входит.
- Риски и как они проверяются.
- Критерии приёмки.
- Внешние расходы.
- Порядок изменения scope.
- Условия гарантии и поддержки.
Если предложение состоит из одной суммы и обещания «сделаем под ключ», сравнивать подрядчиков невозможно.
Где экономить можно, а где опасно
Можно сократить первую версию, число ролей, редкие сценарии и декоративные функции. Можно временно оставить ручной шаг, если он явно обозначен и не ломает безопасность.
Опасно выкидывать резервные копии, контроль прав, обработку повторов, мониторинг и приёмку. Эти вещи не выглядят на презентации, но определяют стоимость инцидента.
Что подготовить заказчику
- Один приоритетный процесс и его владелец.
- Реальные примеры данных без лишних персональных сведений.
- Список интеграций и контакты их владельцев.
- Три главных пользовательских сценария.
- Цена ошибки и недоступности.
- Желаемая дата и причина, почему она важна.
- Критерии, по которым первая версия будет принята.
После этого разговор о цене становится предметным. До этого точная цифра — не профессионализм, а ставка на то, что неизвестные потом оплатит заказчик.
Сравнение
Блоки сметы
| Блок | Что входит |
|---|---|
| Discovery | Процесс, роли, границы, baseline и неизвестные |
| Engineering | Frontend, backend, интеграции, данные и миграция |
| Quality | QA, безопасность, приёмка, backup и recovery |
| Operations | CI/CD, мониторинг, запуск, обучение и поддержка |
Что проверить
Что попросить в коммерческой оценке
- Результат каждого этапа, а не только список специалистов.
- Допущения, внешние расходы и то, что не входит.
- Причины резерва и способ проверить риски.
- Критерии приёмки и порядок изменения scope.
- Гарантию, поддержку, SLA и передачу продукта.
Как мы подходим к задаче
CENTURY не обещает точную стоимость сложной системы после короткого звонка. Discovery и техническая проверка нужны, чтобы диапазон опирался на доказательства, а не превращался в поздние change requests.