Смена подрядчика по клиентской части
Приемка унаследованного фронта: можно ли сопровождать, где знания только в головах, сколько стоит вход новой команды.
Клиентская часть кабинета, портала или SPA/SSR: структура, состояние, доставка UI, цена изменений. Часто стек уже есть — React, Next, TypeScript — а пользы мало. Или фронт выносят из монолита на шаблонах: курс верный? Отчет отдадите любой команде.
Для продуктов, где фронтенд — рабочий инструмент: личный кабинет, B2B-портал, админка, клиентская часть с авторизацией, состоянием и запросами к API. Смотрим так, как сами будем чинить и передавать код. Сюда же — продукт на стыке эпох: часть экранов еще в монолите на серверных шаблонах, часть уже в отдельном клиентском слое, часто силами бэкенд-команды. Аудит показывает, идет ли вынос к сопровождаемому приложению или копирует серверные привычки в новый стек.
Лендинг из нескольких экранов без логики сюда не относится — там другой объем и другие вопросы. Если нужен срез всей системы, начните с технического аудита или добавьте бэкенд и инфраструктуру после фронта. Исправления после отчета — у себя, у текущего подрядчика или у нас.
Приемка унаследованного фронта: можно ли сопровождать, где знания только в головах, сколько стоит вход новой команды.
Next, React или TypeScript в зависимостях, а на практике — длинные страницы вместо компонентов, типы-заглушки, SSR не по назначению. Нужна независимая картина.
Часть UI еще в серверных шаблонах, часть уже в новом клиенте. Бэкендеры выносят экраны «как им понятно». Нужно понять: курс верный или закрепляете долг на годы.
Долгий первый экран, тяжелые страницы кабинета, рост жалоб на скорость. Ищем причины в клиентском слое по коду и сборке — без боевых нагрузочных замеров.
Одинаковые куски интерфейса в трех местах, состояние расползлось по экранам, правка одного экрана ломает соседний.
«У нас современный фронт» против фактов сопровождаемости — материал для переговоров, проверки при сделке или перед наймом фронтенд-людей и ростом числа экранов.
Углубление клиентского слоя. В общем техническом аудите — укрупненные зоны всего контура; здесь — что именно разбираем во фронтенд-приложении
Разбит ли интерфейс на переиспользуемые части или это длинные страницы «как HTML», только в новом стеке. В том числе наследие шаблонов монолита: экраны и логика «как на сервере».
Где живет состояние, как экраны делят данные, где дубли и скрытые связи между модулями.
Что реально отдается с сервера, что собирается только в браузере. Симптомы вроде белого экрана и «формы, которая оживает через секунды» — без лекции по фреймворку.
Первый экран, тяжелые маршруты, размер бандла, Core Web Vitals как ориентир. Смотрим код и метрики сборки, без боевых замеров на проде.
Как клиент ходит за данными: лишние запросы, хрупкие контракты, смешение ответственности интерфейса и сервера.
TypeScript «для галочки», дубли, мертвые зависимости, насколько дорого ввести нового человека в клиентский слой.
Документация, соглашения в репозитории, готовность фронта к передаче новой команде или подрядчику.
Типовые риски: секреты в бандле, опасные практики хранения токенов. Без пентеста и эксплуатации уязвимостей.
Опираемся на код клиентского приложения и артефакты сборки. Продуктовый UX, пентест, боевая нагрузка и полный разбор сервера — отдельные услуги
Не подтверждаем сценарии по ТЗ и не ведем приемочное тестирование экранов
Не оцениваем бизнес-решения и состав функций продукта
Не делаем UX-аудит и редизайн
Не проводим пентест и не снимаем боевые нагрузочные замеры на проде
Не правим код в объеме аудита — только диагностика и план
Не подменяем полный аудит бэкенда, данных и инфраструктуры
Не выдаем юридическое заключение и сертификацию
Не считаем один прогон Lighthouse окончательным вердиктом по слою
Редактируемые документы остаются у вас: как ТЗ на доработки фронта, аргумент в переговорах или основание для решения по слою
Состояние клиентского слоя, находки со ссылками на модули и файлы, приоритеты, итоговая оценка. Команда может начать работу без повторного погружения.
Как устроена клиентская часть, где опасные связи и границы со старыми шаблонами — навигатор для новой команды.
Версии против актуальных, лицензионные риски, кандидаты на удаление.
Где уместно: тяжелые точки сборки и количественная картина сопровождаемости — не впечатления, а цифры по модулям.
Что чинить сразу, что отложить, где дешевле пересобрать слой, чем латать точечно.
Бюджетные ориентиры по этапам — для планирования и переговоров с подрядчиком или инвестором.
Отчет рассчитан на передачу любой команде. Можно чинить фронт силами инхауса или текущего подрядчика — без обязательного продолжения с нами. Если нужен исполнитель на устранение долга под ключ — аутсорсинг разработки. Если нужны люди в вашу команду под вашим управлением — аутстаффинг.
Согласуем объем, NDA, доступ к репозиторию фронта. По возможности — стенд или артефакты сборки.
Фиксируем границы: только новый клиентский слой, стык со старыми шаблонами или оба мира.
Структура, состояние, доставка UI, производительность восприятия, стык с API, сопровождаемость, передаваемость, типовые риски на клиенте.
Сводим находки и сверяем с вами, что критично сейчас.
Отчет, карта модулей, реестр зависимостей, метрики где уместно, дорожная карта и ориентиры по стоимости.
Отвечаем на вопросы. Дальше чините у себя, у текущего подрядчика или у нас.
Фронтенд — один слой. Можно добавить бэкенд, инфраструктуру или заказать полный контур
Ориентир как у технического аудита. Точный объем фронтенд-слоя уточняем на брифе
Ответим в течение рабочего дня
Уточним задачу и границы фронтенд-слоя
Ориентируем по срокам и бюджету аудита
Согласуем NDA и доступы к репозиторию
Передадим пакет документов по итогам