Чем веб-портал отличается от сайта
Граница проходит по одному признаку: на сайте контент одинаков для всех, в портале у пользователя есть собственные данные и права на них. Как только появляется вход, роль и личная история — заявки, договоры, отгрузки, показания, остатки, — это уже веб-приложение, и делается оно по другим правилам.
Что из этого следует практически. Появляется модель данных, которую нельзя менять на ходу без миграций. Появляются права доступа, которые надо проверять на сервере, а не прятать кнопку в интерфейсе. Появляются нагрузка и отказоустойчивость: упавший корпоративный сайт — неприятность, упавший портал заказов — остановленные продажи. Появляется журнал действий: кто и когда изменил документ.
Поэтому создание веб-портала начинается не с макетов, а с описания сущностей, ролей и сценариев. Дизайн приходит третьим — и это единственный тип проекта, где мы настаиваем на техническом задании как на отдельном оплачиваемом этапе.
Портал на Odoo вместо разработки бэкенда с нуля
Половина корпоративных порталов состоит из вещей, которые уже кем-то написаны: пользователи и права, контрагенты, договоры, заявки со статусами, задачи, документы, уведомления, отчёты. Писать это заново — самый дорогой способ получить личный кабинет.
Odoo закрывает этот слой как готовый бэкенд: в нём уже есть модель контрагентов и документов, права, workflow заявок, портал клиента с входом по ссылке, склад, продажи и бухгалтерия, если они нужны. Разработка сводится к тому, что действительно уникально — ваши сущности, ваши правила и интерфейс под ваших пользователей.
Показательно, что в выдаче этот вариант почти не встречается: в разборе четырнадцати компаний, продающих разработку и интеграции, Odoo не попал ни в один список платформ. Заказчику это стоит денег: там, где хватило бы настройки и модуля, продают месяцы разработки с нуля. Мы считаем оба варианта и показываем разницу до старта.
MVP и масштабирование: цена у каждого шага, а не одна сумма
Главная беда порталов — не техника, а способ покупки. Заказчик просит смету на всё сразу, получает шестизначную цифру и год работ, а через полгода выясняется, что половина функциональности не нужна, зато нужна другая половина, о которой не думали.
Мы режем проект на шаги, у каждого из которых своя цена, свой результат и своя точка выхода. Шаг 1 — MVP: вход, роли, одна ключевая сущность и один сценарий, который снимает основную ручную работу. Шаг 2 — обвязка: интеграции с учётом и оплатой, уведомления, отчёты. Шаг 3 — масштабирование: вторая роль пользователей, мобильный сценарий, нагрузка, отказоустойчивость, журнал действий.
После каждого шага портал работает и приносит пользу, а не лежит в ветке до полной готовности. Если после первого шага выяснилось, что дальше не нужно, — это нормальный финал проекта, а не сорванный контракт.
Личный кабинет, роли и интеграции по API
Что чаще всего заказывают под словами «нужен портал»: личный кабинет клиента с историей заказов и документами; кабинет дилера с персональным прайсом, остатками и заказом по счёту; портал поставщика с заявками и сверкой; интранет для сотрудников с заявками в бухгалтерию и ИТ; кабинет абонента с показаниями и начислениями.
Техническая часть у всех общая: аутентификация (по телефону, почте или через учётную запись компании), роли и права на уровне сервера, работа с документами, уведомления, выгрузки. Отличается модель данных и то, с чем портал разговаривает на другом конце — 1С, Odoo, складская система, платёжный сервис, телефония.
Интеграции делаем по API обеих сторон и всегда с тестовым контуром: портал, который учится обмениваться данными на боевой базе, — это вопрос времени до испорченного документа. Сервер под порталом настраиваем и держим сами, включая резервные копии и мониторинг: у приложения с пользовательскими данными цена простоя другая, чем у сайта-визитки.