Сколько стоит личный кабинет или B2B-портал в 2026 году

Короткий ответ

Стоимость личного кабинета определяется не количеством экранов и не самим наличием входа по паролю. Главные драйверы — роли и права, бизнес-процесс, документы, рабочее пространство команды, интеграции, качество исходных данных и требования к эксплуатации.

Для планирования можно использовать три учебных сценария:

Формат	Граница первой версии	Редакционный ориентир H-Studio
Узкий кабинет V1	Один тип клиента, заявки, статусы, документы, оператор	700 000–1 100 000 ₽
B2B-портал	Несколько ролей, workflow, back office, одна интеграция	1 200 000–2 200 000 ₽
Операционная платформа	Несколько сторон, сложные правила, миграция и интеграционный контур	от 2 200 000 ₽

Это не статистика рынка и не публичная оферта. Диапазоны — составные модели, которые показывают порядок бюджета при заданном scope. Актуальные нижние ориентиры H-Studio на 17 июля 2026 года: архитектурный спринт — от 150 000 ₽, кастомная платформа — от 800 000 ₽. Конкретная цена кабинета появляется после карты ролей, данных и процессов.

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

01 · Кабинет, портал и платформа — не синонимы

В коммерческом предложении эти слова часто используют взаимозаменяемо. Для оценки полезнее разделить их по ответственности системы.

Личный кабинет

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

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

B2B-портал

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

Пример: партнёр создаёт заказ, менеджер проверяет условия, бухгалтер подтверждает оплату, система синхронизирует статус с 1С, а администратор управляет справочниками и доступами.

Кастомная платформа

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

Разница не в масштабе интерфейса. Личный кабинет может состоять из двадцати экранов, а платформа — из десяти. Цена растёт там, где система должна принимать и сохранять больше решений.

02 · Формула бюджета

Рабочая модель оценки выглядит так:

Бюджет кабинета = архитектура процесса + UX/UI + авторизация и права + клиентская часть + back office + данные и документы + интеграции + запуск + проверка качества + резерв на выявленные риски.

Если в смете есть только дизайн и frontend/backend, часть продукта, скорее всего, не посчитана. Ниже — карта компонентов, которую удобно использовать до запроса оценки.

Компонент	Что требуется определить	Почему влияет на цену
Пользователи и организации	Один клиент или несколько компаний, приглашения, блокировки, принадлежность к организации	Меняет модель данных и управление доступом
Роли и права	Клиент, менеджер, оператор, бухгалтер, администратор; права на чтение и действия	Каждое действие нужно проверить и протестировать для каждой роли
Статусы и workflow	Кто переводит объект на следующий этап, возможен ли откат, кто согласует исключение	Создаёт бизнес-логику, уведомления и историю событий
Документы	Загрузка, версии, шаблоны, генерация, подписание, архив	Требует хранения, доступа, проверки форматов и жизненного цикла
Back office	Очередь задач, фильтры, массовые операции, справочники, управление пользователями	Без него клиентский интерфейс часто создаёт новую ручную работу
Уведомления	Email, SMS, push, события внутри кабинета, настройки подписок	Нужны шаблоны, очереди, повторы и контроль доставки
Интеграции	CRM, 1С, ERP, платежи, ЭДО, телефония, внешние API	Добавляет контракты данных, ошибки обмена и сверку состояний
Миграция	Источники, качество справочников, дубли, история	Цена зависит от правил очистки, а не только от числа строк
Безопасность и аудит	2FA, журнал действий, повторное подтверждение, сроки хранения логов	Контроли должны соответствовать рискам и проверяться end-to-end
Эксплуатация	Окружения, CI/CD, мониторинг, резервные копии, восстановление	Определяет, будет ли системой возможно управлять после релиза

03 · Почему «форма с логином» дешевле настоящего кабинета

Экран входа создаёт ощущение, что основная сложность — authentication. На практике вход отвечает только на вопрос «кто пользователь». Система должна ещё решить:

• к какой организации он относится;
• какие проекты, документы и операции ему доступны;
• может ли он пригласить коллегу;
• что произойдёт при смене должности или увольнении;
• кто увидит действие в журнале;
• как восстановить доступ без открытия чужих данных;
• нужны ли 2FA, SSO или повторное подтверждение критичного действия.

OWASP ASVS предлагает использовать требования безопасности не только при тестировании, но и при закупке разработки. Это полезный принцип для оценки: уровень контроля доступа следует за риском приложения, а не добавляется одной задачей «сделать безопасно» в конце проекта.

Особенно быстро scope растёт в multi-tenant-системе, где один портал обслуживает несколько компаний. Проверка «пользователь авторизован» недостаточна: каждый запрос должен учитывать организацию, объект и разрешённое действие. Ошибка в одном фильтре может открыть данные соседнего клиента.

04 · Back office — вторая половина продукта

Клиентский кабинет редко работает сам по себе. Кто-то внутри компании должен:

• увидеть новый запрос;
• проверить данные и вложения;
• назначить ответственного;
• запросить исправление;
• изменить статус с понятной причиной;
• сформировать или загрузить документ;
• обработать исключение;
• найти историю действий;
• помочь пользователю с доступом.

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

Хороший back office не обязан быть большим. Для первой версии достаточно закрыть основной поток и редкие исключения оставить явной ручной операцией. Важно определить владельца ручного шага и предел, после которого он перестанет масштабироваться.

05 · Интеграция — это контракт, а не один endpoint

Фраза «подключить 1С» ничего не говорит о стоимости. Платформа 1С поддерживает разные механизмы: HTTP-сервисы, OData, XML/JSON, планы обмена и специализированные форматы. Выбор зависит от конфигурации, версии, инфраструктуры и того, какая система является источником истины.

До оценки нужно ответить минимум на семь вопросов:

1. Какие сущности передаются: клиенты, договоры, заказы, счета, оплаты, остатки?
2. Обмен односторонний или двусторонний?
3. Кто создаёт идентификатор и какая система хранит эталонное значение?
4. Как часто нужна синхронизация?
5. Что происходит при повторном сообщении или временной недоступности системы?
6. Кто разбирает конфликт данных?
7. Где оператор увидит ошибку и сможет безопасно повторить операцию?

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

То же относится к CRM, платежам и ЭДО. Стоимость определяет не бренд сервиса, а направление обмена, качество API, обработка ошибок и ответственность каждой системы.

06 · Три сценария бюджета

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

Сценарий A: узкий клиентский кабинет — 700 000–1 100 000 ₽

Состав: один тип клиента, один оператор, регистрация или приглашение, профиль, заявки со статусами, загрузка документов, email-уведомления, базовая административная панель, production-развёртывание и передача.

Граница: без платежей, без миграции истории, без 1С, без нескольких клиентских организаций и сложного согласования. Один основной процесс от создания запроса до завершения.

Срок планирования: ориентировочно 8–12 недель после утверждения scope.

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

Сценарий B: B2B-портал — 1 200 000–2 200 000 ₽

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

Граница: адаптивный веб, один основной бизнес-процесс и ограниченная миграция подготовленных справочников. Без нативного приложения, offline и сложного биллинга.

Срок планирования: ориентировочно 12–18 недель.

Главный риск здесь — не интерфейс, а согласование состояний между порталом и учётной системой. Если источник истины не определён, одна и та же заявка начнёт жить в двух версиях.

Сценарий C: операционная платформа — от 2 200 000 ₽

Состав: несколько сторон, объектные права, сложные workflow, платежи или биллинг, генерация документов, две и более интеграции, миграция, расширенная операторская панель, аналитика и отдельные требования к доступам и данным.

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

Срок планирования: от 16 недель; фазы поставки определяются после карты зависимостей.

На этом уровне нельзя уменьшить цену, оставив тот же scope и просто «ускорив разработчиков». Сокращать нужно число процессов, интеграций или вариантов поведения первой версии.

07 · Что сильнее всего удорожает портал

Не количество ролей, а различие их поведения

Пять ролей с одинаковым доступом к одному проекту могут быть простыми. Две роли со сложными исключениями — дорогими. Для оценки полезна матрица «роль × объект × действие», а не список должностей.

Документы с жизненным циклом

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

Грязные исходные данные

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

Индивидуальные правила клиентов

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

Требования к данным и доступам

Персональные, финансовые, кадровые и другие чувствительные данные требуют заранее согласовать состав данных, места обработки, роли, журналирование, хранение и удаление. Нельзя честно продавать универсальный ярлык «соответствует 152-ФЗ» без юридической модели конкретного оператора. Технический scope следует из требований клиента и его профильного специалиста.

08 · Как снизить цену без создания долга

Оставить один завершённый путь

Лучше довести один сценарий «клиент отправил → команда обработала → клиент получил результат», чем наполовину собрать кабинет, аналитику, чат, базу знаний и программу лояльности.

Использовать приглашения вместо сложной регистрации

Для закрытого B2B-продукта самостоятельная регистрация, проверка компании и восстановление владения могут быть не нужны в V1. Менеджер создаёт организацию и приглашает администратора клиента.

Не переносить всю историю

Можно импортировать активные договоры и открытые проекты, а старый архив оставить read-only в прежней системе. Это допустимо только после проверки обязанностей по хранению и реальных сценариев доступа.

Начать с одного направления обмена

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

Взять готовый компонент для неключевой функции

Объектное хранилище, рассылки, мониторинг и базовая authentication-инфраструктура не обязаны разрабатываться с нуля. Но аккаунты, данные и возможность сменить провайдера должны оставаться под контролем заказчика.

Сначала снять самый дорогой риск

Если неизвестно качество API 1С или исходных данных, короткий технический spike и пробная выгрузка полезнее детальной сметы на предположениях.

09 · Готовое решение или кастомная разработка

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

Кастомная разработка не является автоматически лучшим вариантом. Если готовый CRM-портал закрывает процесс на 80% без критичных обходов, дешевле изменить операцию, чем строить собственную платформу. Кастом оправдан, когда ограничения готового продукта мешают основному процессу, безопасности, интеграциям или клиентскому опыту.

10 · Как поставлять по этапам

Последовательность уменьшает риск лучше, чем попытка сразу зафиксировать весь будущий продукт.

1. Карта процесса. Пользователи, роли, объекты, статусы, данные, внешние системы и исключения.
2. Архитектурный scope. Граница V1, модель данных, источники истины, интеграционные контракты, риски и критерии приёмки.
3. Вертикальный срез. Один сценарий проходит через клиентский интерфейс, backend и back office на тестовых данных.
4. Рабочая V1. Нужные роли, документы, уведомления, критичная интеграция, эксплуатационный контур и передача.
5. Ограниченный запуск. Первая группа пользователей, журнал проблем, проверка ручных операций и фактической нагрузки.
6. Следующая фаза. Только после данных решается, какие исключения автоматизировать и какие модули действительно нужны.

Каждый этап должен завершаться артефактом, который остаётся у заказчика: схема, репозиторий, развернутая версия, документация или отчёт о пилоте.

11 · Что показывают релевантные кейсы

My Office Asia: кабинет как редакционный инструмент

В My Office Asia публичный каталог гибких офисов связан с закрытой административной CMS. Команда клиента управляет объектами, изображениями и контентом, а архитектура подготовлена к нескольким рынкам. Этот пример показывает, что цена «кабинета» зависит не от логина, а от модели данных каталога, редакционного процесса и права команды самостоятельно управлять продуктом.

Vulken FM: портал вокруг полевого процесса

В Vulken FM веб-платформа связана с мобильным сценарием инспекций: QR-доступ к активам, offline-сбор, формы, структурированная отчётность и рабочий контур команды. Здесь стоимость двигают синхронизация, состояние данных без сети и прослеживаемость инспекции — не число страниц в интерфейсе.

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

12 · Чек-лист перед запросом сметы

Подрядчик сможет дать более содержательную оценку, если получит ответы на следующие вопросы:

1. Кто внешний пользователь и какую задачу он должен завершить без менеджера?
2. Какие внутренние роли участвуют в том же процессе?
3. Какие объекты существуют: проект, заказ, заявка, договор, актив?
4. Какие статусы у каждого объекта и кто их меняет?
5. Какие документы загружаются, создаются или подписываются?
6. Какая система является источником истины для клиента, цены, заказа и оплаты?
7. Какие интеграции обязательны для первого запуска?
8. Есть ли документация API и тестовый контур?
9. Какие данные нужно перенести и можно ли показать обезличенный пример?
10. Какие требования к данным и доступам подтверждены специалистами клиента?
11. Сколько организаций и пользователей ожидается на первом этапе?
12. Кто будет поддерживать продукт после запуска?

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

Итог

Личный кабинет стоит столько, сколько стоит замкнуть конкретный процесс между клиентом и командой. Авторизация и интерфейс — только видимая часть. Реальный бюджет формируют права, статусы, документы, back office, интеграции, качество данных и готовность системы к эксплуатации.

Для первичного планирования можно держать ориентиры от 700 000 ₽ за узкий кабинет, 1 200 000–2 200 000 ₽ за B2B-портал и от 2 200 000 ₽ за платформу с несколькими контурами. Это составные модели, а не прайс рынка. Проверяемая смета начинается с карты ролей и данных.

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

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

Сколько стоит самый простой личный кабинет?

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

Можно ли сделать кабинет за 300 000 ₽?

Можно собрать прототип, узкий внутренний инструмент или авторизованную витрину с минимальной логикой. Для production-кабинета, где клиент передаёт данные, а команда обрабатывает процесс, такой бюджет обычно требует заметно уменьшить scope или использовать готовый продукт.

Сколько длится разработка B2B-портала?

Сфокусированный кабинет V1 обычно планируется на 8–14 недель после утверждения scope. Портал с несколькими ролями, интеграцией и повышенными требованиями к данным — дольше. Срок зависит от готовности API и данных не меньше, чем от работы интерфейса.

Что выбрать: готовый CRM-портал или кастомный?

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

Интеграция с 1С всегда сильно увеличивает бюджет?

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

Входит ли мобильное приложение в стоимость портала?

Адаптивная веб-версия — да, если она входит в scope. Нативные приложения и offline-синхронизация — отдельные контуры. Их стоит добавлять, когда мобильный сценарий действительно требует камеры, геопозиции, push, фоновой работы или устойчивости без сети.

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

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

---

Нужна карта продукта и проверяемая смета? Начните с architecture sprint. Описание формата кабинета — portals, сложной операционной системы — custom software, интеграционного контура — integrations. Общую модель бюджета продукта мы разобрали отдельно: Сколько стоит разработать MVP в России в 2026: бюджет без магии.

Источники и методика

• OWASP Application Security Verification Standard 5.0 — открытый стандарт требований к проверке безопасности веб-приложений; использован как источник принципа risk-based контроля доступа. Проверено 17 июля 2026 года.
• 1С:Предприятие — обмен данными — официальный обзор механизмов интеграции и устойчивого обмена. Проверено 17 июля 2026 года.
• 1С:Предприятие — формат EnterpriseData — официальный пример обмена с нумерацией и подтверждением получения сообщений. Проверено 17 июля 2026 года.
• Публичные форматы и границы H-Studio: portals, custom software и architecture sprint.
• Подтверждаемые примеры продукта: my office asia и vulken fm.

Диапазоны трёх сценариев — редакционные модели H-Studio для объяснения влияния scope. Они не являются статистическим исследованием рынка, юридической консультацией или публичной офертой.