B2B-портал на Laravel — это не «сайт, который сделали и забыли». Это живая система, где заказчики оформляют заказы, менеджеры согласуют скидки, а интеграции тянут данные из 1С и CRM. После запуска начинается самое интересное: поддержка, доработки и контроль стоимости владения. В этой статье мы разберём, из чего складывается бюджет, какие задачи возникают чаще всего и как не утонуть в бесконечных правках.
Автор: Григорий Федотов, основатель студии · Обновлено: 08.10.2026
Когда мы считаем TCO (total cost of ownership) для портала на Laravel, то всегда раскладываем его на несколько слоёв. Первый — инфраструктура. Хостинг, база данных, Redis, очереди, S3-хранилище для файлов. Для B2B-портала обычно нужен не самый дешёвый виртуал, а конфигурация с запасом по памяти и диску. Второй слой — поддержка кода. Даже если портал работает стабильно, выходят обновления Laravel, PHP, пакетов. Их нужно тестировать и ставить. Третий — доработки. Бизнес меняется: появляются новые филиалы, правила ценообразования, роли. Четвёртый — внутренние затраты вашей команды: время менеджеров на обучение, написание техзаданий, приёмку. Пятый — лицензии на сторонние сервисы: отправка SMS, онлайн-оплата, ЭДО, карты. Если сложить всё это, получается вполне конкретная сумма в год. Многие заказчики удивляются, что поддержка стоит не 5 тысяч рублей в месяц, а заметно больше. Но за этими деньгами стоит команда, которая держит систему в рабочем состоянии.
Мы часто видим, как на старте экономят на хостинге: берут shared-хостинг за 300 рублей. Через полгода портал падает от нагрузки, потому что 50 менеджеров одновременно выгружают прайсы. На B2B-портале лучше сразу закладывать VPS или облако с возможностью масштабирования. База данных — отдельно, Redis — для кэша и очередей. Лицензии на сторонние API тоже стоит учитывать: например, SMS-шлюз для уведомлений, подписка на карты для автозаполнения адресов.
Laravel выпускает новую мажорную версию раз в год. Если не обновляться, через два-три года проект становится сложно поддерживать: пакеты перестают совместимы, появляются уязвимости. Мы обычно планируем обновление раз в год-полтора, с предварительным тестированием на отдельном стенде. Это отдельная статья бюджета, но она дешевле, чем аварийный переезд.
Доработки — самая непредсказуемая часть. Мы советуем заказчикам вести бэклог: список хотелок и болей. Раз в месяц приоритизировать и брать в работу несколько задач. Так бюджет распределяется равномерно, без авралов.
После релиза мы обычно не уходим сразу. Первый месяц — гарантийная поддержка: исправляем баги, которые вылезли на реальных данных. Потом переходим в режим регулярной поддержки. Что в неё входит? Мониторинг доступности, проверка логов, обновление зависимостей, консультации по телефону. Плюс мелкие правки: поменять текст, поправить вёрстку, добавить поле в форму. Всё это фиксируется в часах. Мы используем пакет часов: например, 20 часов в месяц. Если задача не влезает, переносим на следующий месяц или выделяем отдельно. Так заказчик видит бюджет и не получает сюрпризов.
B2B-портал может упасть ночью, когда менеджеры спят. Но если утром они не могут отгрузить товар, это простой. Поэтому мы настраиваем мониторинг: проверка HTTP-статуса, доступность БД, длина очередей. При падении система шлёт алерт в Telegram. В SLA прописываем время реакции: критичные инциденты — в течение часа, остальные — в течение рабочего дня.
Раз в квартал мы прогоняем composer outdated и смотрим, какие пакеты устарели. Обновляем осторожно, на тестовом стенде. После обновления обязательно прогоняем автотесты, если они есть. Если тестов нет, проверяем ключевые сценарии вручную: вход, оформление заказа, выгрузку в 1С.
За несколько лет поддержки мы собрали типовой список доработок, которые заказывают чаще всего. Первое — интеграции. Клиенты хотят синхронизировать остатки, цены, статусы заказов с 1С или ERP. Второе — роли и права. Появляются новые отделы, филиалы, партнёры. Нужно гибко настраивать доступ. Третье — личный кабинет. Добавить историю заказов, повторный заказ, скачивание документов. Четвёртое — отчёты и аналитика. Руководству нужны срезы по продажам, дебиторке, активности клиентов. Пятое — уведомления. SMS, email, push в личном кабинете. Шестое — оптимизация производительности. Когда база растёт, запросы начинают тормозить. Помогает кэширование, индексы, вынос тяжёлых операций в очереди.
Интеграция с 1С — больная тема многих порталов. Мы обычно делаем обмен через промежуточную БД или API. Важно настроить логирование ошибок и повторные попытки. Если 1С недоступна, данные не должны теряться.
Laravel даёт удобные инструменты для разграничения прав: Gates, Policies. Мы настраиваем роли так, чтобы менеджер видел только своих клиентов, а администратор — всё. Это снижает риск ошибок и утечек.
Стоимость поддержки мы считаем исходя из сложности портала и требуемого SLA. Есть три основных модели: пакет часов, выделенная команда и разовые работы. Пакет часов подходит, если задачи небольшие и нерегулярные. Выделенная команда — если портал активно развивается и нужна быстрая реакция. Разовые работы — для конкретных проектов, например, обновление Laravel. В каждой модели мы фиксируем ставку за час и прозрачно отчитываемся. Заказчик видит, сколько часов ушло на задачу. Мы не скрываем, если задача оказалась сложнее — предупреждаем заранее.
Обычно это 10, 20 или 40 часов в месяц. Часы не сгорают, если переносятся на следующий месяц (по договорённости). Подходит для стабильных порталов.
Если портал — ядро бизнеса, лучше держать выделенного разработчика и тестировщика. Они погружены в проект и решают задачи быстрее. Стоимость выше, но и скорость реакции другая.
Когда нужно сделать конкретную фичу, мы оцениваем её отдельно. Это может быть интеграция, новый раздел, оптимизация. После оценки фиксируем сроки и бюджет.
| Модель | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Пакет часов | Стабильный портал, редкие правки | Прозрачный бюджет, часы переносятся | Нет мгновенной реакции |
| Выделенная команда | Активное развитие, высокие нагрузки | Быстрая реакция, погружение в проект | Дороже, нужна загрузка |
| Разовые работы | Чёткая задача, обновление, интеграция | Фиксированная цена | Нет постоянной поддержки |
Если вы меняете подрядчика или передаёте проект своей команде, вот что стоит сделать. Во-первых, соберите доступы: сервер, репозиторий, база, админки сервисов. Во-вторых, проверьте наличие документации: описание архитектуры, схемы БД, инструкции по развёртыванию. В-третьих, убедитесь, что есть тесты. Если нет — закажите аудит и напишите хотя бы smoke-тесты. В-четвёртых, настройте мониторинг и алерты. В-пятых, проведите встречу с новой командой, расскажите о болях и планах. В-шестых, зафиксируйте SLA и модель поддержки. В-седьмых, проверьте, что все внешние интеграции работают на тестовом стенде. В-восьмых, убедитесь, что есть актуальный бэкап и план восстановления. После этого можно передавать проект.
Часто проекты передают с хаосом в доступах. Мы советуем завести менеджер паролей и выдать доступы через него. Документацию можно вести в виде markdown-файлов в репозитории.
Без тестов любая доработка — лотерея. Мы обычно пишем feature-тесты на ключевые сценарии. Мониторинг настраиваем через бесплатные или платные сервисы: UptimeRobot, Sentry, Laravel Telescope в dev-режиме.
Экономия не в том, чтобы платить меньше, а в том, чтобы избегать аварий и переделок. Первое — не копите мелкие баги. Они имеют свойство превращаться в большие проблемы. Второе — планируйте доработки заранее, а не в режиме «нужно вчера». Срочность всегда дороже. Третье — инвестируйте в тесты и документацию. Это снижает время на онбординг новых разработчиков. Четвёртое — используйте стандартные решения Laravel, не изобретайте свои фреймворки. Пятое — заказывайте аудит раз в год, чтобы выявить узкие места. Шестое — обучайте свою команду: менеджеры должны понимать, как работает портал, чтобы не ставить невыполнимых задач.
Мы советуем закладывать на поддержку и доработки не менее 10-15% от стоимости разработки в год. Если портал сложный, с интеграциями, то до 20%. Это позволяет держать систему в тонусе.
Аудит помогает найти медленные запросы, дублирование кода, устаревшие пакеты. После аудита мы составляем план работ на полгода. Это дисциплинирует и заказчика, и нас.
В итоге, B2B-портал на Laravel — это актив, который требует внимания. Но если подойти к поддержке системно, он будет приносить прибыль, а не головную боль. Мы в вебпоиск.рф всегда начинаем с аудита и честной оценки. Если хотите обсудить ваш проект — пишите, посмотрим, что можно сделать.
B2B-портал — это интеграции с 1С, CRM, личными кабинетами, сложной логикой цен и остатков. Поддержка включает не только обновления, но и мониторинг очередей, синхронизаций, проверку ошибок в логах Laravel. Без этого бизнес-процессы ломаются незаметно.
Да, если код покрыт тестами, есть документация и настроены миграции. Мы обычно начинаем с аудита: смотрим на качество кода, зависимости, наличие тестов. После этого можно передать проект новой команде с минимальными рисками.
Расширение интеграций с 1С и CRM, новые роли и права доступа, доработка личного кабинета, добавление аналитики и отчётов. Часто всплывают задачи по оптимизации запросов и кэшированию при росте нагрузки.
TCO складывается из хостинга, поддержки, лицензий, доработок и внутренних трудозатрат заказчика. Мы помогаем заказчику вести бюджет: фиксируем ежемесячный пакет часов, отдельно планируем крупные доработки. Это даёт прозрачность и предсказуемость.
Реакция на инциденты: падение сайта, ошибки 500, сбои интеграций, проблемы с оплатой. Восстановление из бэкапа, откат релиза, исправление горячих багов. Обычно мы даём гарантированное время реакции в SLA.
Оставьте контакт — пришлём расчёт и предложим решение под вашу задачу. Ни к чему не обязывает.
Без навязчивых звонков · Смета бесплатно · Оплата поэтапно по договору
или позвоните: +7 (495) 487-44-70