Посетитель
Ищет подрядчика: смотрит карточки компаний, услуги, отзывы и статьи. Ему нужна доступная витрина, а не «страница временно не работает».
Кейс: доработка портала строительных услуг
После предыдущего подрядчика каталог исполнителей строительных услуг был нестабилен: ломались сценарии, часть витрины была недоступна.
В первом спринте закрыты критичные ошибки. Дальше — 3–5 модулей по приоритету заказчика: кабинеты, отчёты, админка. Релизы стали регулярными, систему с нуля не переписывали.
Карточка проекта
Результат
Первый спринт
критичные ошибки закрыты, витрина снова доступна
Сопровождение
3–5 модулей: кабинеты, отчёты, админка
Релизы
предсказуемый цикл, не пакет «раз в полгода»
База каталога
сохранена, модули наращивали поверх
| Что внедрили | Как работает |
|---|---|
| Витрина каталога | Компании, услуги, отзывы и статьи снова открываются посетителю |
| Карточки исполнителей | Город, контакты, график, рейтинг и описание услуг на одной карточке |
| Заявка на публикацию | Компания подаёт заявку с витрины, модерация идёт в админке |
| Кабинеты и отчёты | Внутренние сценарии по приоритету заказчика, без отдельной CRM |
Задача
Вернуть каталогу стабильную работу: закрыть накопленные баги, восстановить витрину и доработать сценарии для посетителей, исполнителей и администраторов. Переписывать систему с нуля не требовалось — данные компаний уже были в базе.
Как было
- часть страниц витрины недоступна или падает на сценарии
- ошибки предыдущего подрядчика копились без регулярных релизов
- админка и кабинеты не закрывали приоритеты заказчика
Как стало
- каталог снова открывается: компании, услуги, отзывы, статьи
- критичные регрессии закрыты в первом спринте
- модули и правки уходят короткими релизами по приоритету
Кто пользуется каталогом
Портал — не лендинг строительной компании, а витрина исполнителей. У каждого своя задача, и ломать её из‑за бага в чужом сценарии нельзя.
Исполнитель
Подаёт заявку на публикацию компании, ведёт карточку: город, телефоны, график, описание работ. Дальше — кабинет, если модуль уже в приоритете.
Администратор
Модерирует заявки, правит карточки, смотрит отчёты. Админка дорабатывалась по мере стабилизации, а не пакетом «когда-нибудь потом».
Как устроена работа
-
Стабилизация
Сначала ошибки, из‑за которых витрина была недоступна или ломала сценарии. Пока каталог падает, наращивать модули бессмысленно: каждый релиз ломал бы уже сломанное.
-
Каталог на существующей базе
Компании, услуги и отзывы не переносили в новую систему. Карточки, заявка на публикацию и информационные разделы остаются в том же Laravel-контуре. Поэтапный запуск модулей поверх legacy — типичный сценарий, его же разбираем в FAQ про миграцию.
-
Модули по приоритету
Кабинеты, отчёты, доработки админки — не «весь портал сразу», а 3–5 кусков, которые заказчик ставил первыми. Заявки и карточки компаний живут в рабочем контуре, без отдельной CRM: тот же принцип, что в FAQ про CRM внутри портала.
-
Регулярные релизы
Сопровождение идёт короткими поставками по текущему коду. Баг или модуль не копятся полгода, а уходят в ближайший цикл, когда приоритет подтверждён.
Что добавили после стабилизации
Витрина
Каталог компаний, услуги, отзывы, статьи. То, что посетитель видит без авторизации и что нельзя оставлять «на потом».
Заявки на публикацию
Исполнитель отправляет компанию с витрины. Заявка попадает в админку, а не в почту и переписку с предыдущим подрядчиком.
Кабинеты и отчёты
Внутренние сценарии для тех, кто уже в каталоге: статус карточки, обращения, выборки для администрации.
Админка
Модерация, правки карточек, отчёты. Дорабатывали по приоритету, а не ждали «большой» переработки всего бэка.
Почему Laravel
Портал уже был на Laravel. Менять стек ради смены стека здесь нечего: база компаний, витрина и админка уже связаны.
Задача — разобрать существующий код, закрыть регрессии и нарастить модули. Когда ремонт выгоднее переписки — в интервью про legacy Laravel.
Ограничения
В открытом описании
- стек, состав каталога и характер сопровождения
- скрин публичной витрины — без админки и кабинетов
Не публикуем
- название заказчика и операционные метрики
- внутренние экраны кабинетов и отчётов
Частые вопросы
Это новый портал или доработка?
Доработка существующего Laravel-проекта после предыдущего подрядчика. Каталог исполнителей уже был; с нуля систему не переписывали.
Почему не переписали с нуля?
Витрина и данные уже работали, ломались отдельные сценарии. Дешевле стабилизировать контур и нарастить модули, чем собирать каталог заново. Критерии «ремонт или переписка» — в интервью про legacy.
Что видит посетитель каталога?
Карточки исполнителей с городом, контактами и рейтингом, услуги, отзывы, статьи и заявку на публикацию компании. Кабинеты и отчёты остаются за авторизацией.
Что добавляли после стабилизации?
3–5 модулей по приоритетам заказчика: личные кабинеты, отчёты, доработки админки. Дальше — регулярные релизы по тому же контуру.
Как забирают проект после другого подрядчика?
Сначала доступность и критичные ошибки, затем модули поверх той же базы. Не «вычистить всё и начать заново», а вернуть витрину в работу и наращивать то, чего не хватает. Похожий порядок — в FAQ про миграцию со старой системы.
← Все кейсы · когда ремонтировать Laravel, а не переписывать · заказать разработку Laravel-проекта · Контакты