Без менеджеров-посредников
На связи тимлиды проекта. Про любое решение по интерфейсу можно спросить и получить объяснение, почему сделали так.
Берем клиентскую часть целиком: от макетов до запуска интерфейса. Пока пишется бэкенд, фронтенд работает с сервером-заглушкой по согласованному контракту API.

Свой фронтенд-отдел приходится нанимать, обучать и удерживать. Интерфейс при этом видит каждый пользователь, и по нему решает, остаться или уйти. Если UI для компании не профильная работа, держать под него штат дорого.
Аутсорсинг фронтенда подходит, когда макеты или ТЗ готовы, а команды на клиентскую часть нет. Второй случай: бэкенд и фронтенд идут с разной скоростью, и одна сторона ждет другую. Фронтенд забираем целиком: за вами продукт, за нами работающий интерфейс в браузере.
Фронтенд стартует до готового бэкенда: работаем с сервером-заглушкой и неполным API
Сложные интерфейсы собираем без обходных решений: информационные панели, перетаскивание, визуальные редакторы
Макеты разбираем до разработки: похожие по смыслу элементы с разным оформлением сводим к одному компоненту, и CSS с бюджетом не растут
Стек выбираем под задачу: публичной странице для поиска нужен SSR, закрытому приложению он лишний
Мобильную версию и работу в разных браузерах проверяем на том же этапе, что и основные экраны
Скорость загрузки и отклик интерфейса держим в зеленой зоне Lighthouse и Google PageSpeed Insights
Шесть правил, по которым ведем фронтенд-проекты
На связи тимлиды проекта. Про любое решение по интерфейсу можно спросить и получить объяснение, почему сделали так.
Договоренности, контракт API и задачи живут в системе управления задачами. Любое решение можно найти по задаче: кто, что и когда согласовал.
Готовые экраны выкладываем на тестовый стенд, доступ к нему у вас постоянный. Смотреть интерфейс можно в любой день, не дожидаясь демонстрации.
Контракт API согласуем с бэкендом до кода и назначаем ему владельца. Меняется спецификация — владелец обновляет контракт, и правку видят обе команды.
Фронтенд строим как систему с общими правилами. Отступы, цвета, типографику и скругления задаем токенами дизайна через CSS-переменные, случайных чисел в стилях нет. Компоненты живут в Storybook, шкала токенов настроена в Tailwind CSS. Новый экран сначала собираем из готовых примитивов и пишем новый код, только если их не хватает.
Исходный код, права и окружения ваши. Закрытых платформ не используем, репозиторий и доступы передаем вместе со сдачей.



Успех продукта решает рынок. Аутсорсинг снимает с заказчика найм, управление разработкой и зависимость от одного человека
В проектной разработке счет и акт выставляем по каждому сданному этапу, к ним прилагается журнал часов с разбивкой по задачам. Деньги уходят на экраны, которые уже работают, а для расчета ROI у вас есть точная сумма вложений.
Состав подбираем под этап: разработчика на React, Vue или Angular, тестировщика к приемке, бэкенд-разработчика на интеграцию. Задача закрыта, и специалист уходит с проекта.
У компании опыт копится в процессах. На каждое изменение запускаются автотесты, код сверяют с методологией, общей для всей команды. WS DEV на рынке с 2009 года. Интеграции и связку фронтенда с бэкендом мы собирали много раз и знаем, где они обычно ломаются. Фрилансер или единственный штатный разработчик работает на своем опыте: его ошибку некому заметить, а с его уходом знания о проекте уходят вместе с ним.
Подготовка к старту короче, чем при сборе своей команды, и TTM сокращается. Команда уже собрана, вакансий и собеседований нет. Операционная рутина у нас автоматизирована, и организация работы не отнимает время у разработки. Подходы, проверенные на прошлых проектах, заново не изобретаем.
Продукт сдаем в заказанном объеме, дальше решение за вами: развивать его своими силами, с другой командой или с нами. Выкупать код не придется, поэтому в TCO не попадает плата за привязку к подрядчику.
За работы по договору отвечает компания. Если сданный экран работает не так, как записано в требованиях, это дефект, и мы устраняем его по гарантии.
Типовую задачу закрывает коробочный продукт. К нам приходят с нестандартной, когда готовое решение не справилось. В таких проектах риски разбираем до старта, главные для фронтенда собраны ниже.
Одна команда опережает, другая простаивает в ожидании.
Поднимаем сервер-заглушку, который отдает данные по согласованному контракту
Интерфейс разрабатываем на неполном API, без простоя
До старта фиксируем спецификацию в OpenAPI или Swagger, и обе команды сверяются с ней
«Бэкенд сломал» — «фронтенд неправильно вызывает». Ошибка висит, пока идет спор.
Назначаем контракту API одного владельца
Стык фронтенда и бэкенда покрываем контрактными и интеграционными тестами
Первые демонстрации проводим на тестовом стенде с реальными данными
Методы API появляются, пропадают, меняют формат ответа.
Спецификацию API согласуем до начала разработки
Каждое изменение API заводим задачей в системе управления задачами
Если фронтенд и бэкенд выходят разными релизами, версионируем API
Таблица на 10 000 строк прокручивается рывками, анимации дергаются.
Профилируем интерфейс до релиза, пока пользователи не начали жаловаться
В длинных списках отрисовываем только видимые строки, модули подключаем ленивой загрузкой, бандл делим по маршрутам
В сборке на Vite или Webpack настраиваем удаление неиспользуемого кода
Время на оптимизацию скорости закладываем в оценку проекта
В макете пять видов кнопок и у каждого поля свой отступ. В коде это пять компонентов и сотни строк CSS.
На старте разбираем макеты и сводим похожие по смыслу элементы к одному компоненту
Токены дизайна и шкалу отступов дизайнер и разработчик берут из одного источника
Компоненты ведем в Storybook и при проверке кода сверяем с библиотекой
Разовый элемент сначала собираем из готовых примитивов, новый компонент добавляем по согласованию
Внутренней панели управления SSR добавляет лишнюю сложность. Лендинг на чисто клиентском React плохо индексируется.
Сначала смотрим, что строим: закрытое приложение или публичный сайт, нужен ли поиск
Индексируемые страницы собираем на Next.js или Nuxt, остальное делаем SPA
Выбор записываем в ТЗ до старта и по ходу не пересматриваем
Формат договора подбираем под зрелость продукта и готовность к риску. Один шаблон контракта на все задачи не навязываем.
Подходит, когда гипотезы меняются быстрее плана. Вы проверяете идеи, мы пишем под них код без жесткой оценки и сроков. Платите за фактические часы по итогам периода. Сырую версию доводим в следующих итерациях: важнее выйти раньше.
Задача понятна, окупаемость посчитана. Составляем ТЗ, фиксируем бюджет и сроки до старта, и счет по ходу работы не меняется. Подходит отлаженному бизнесу, которому нужен предсказуемый результат.
Оплата: фиксированная по оценке, Fixed Price
Кому: бизнесу с понятным экономическим эффектом
Дорожная карта есть, но по ходу в нее приходят правки. Работаем по рамочному договору: оцененные релизы по фиксированной цене, все сверх объема по часам.
Оплата: фиксированная цена за релизы, сверх объема по часам
Кому: проектам с планом, который будет меняться
Выясняем, что и зачем строим: задаем вопросы, собираем требования, готовим документацию.
Проектируем сценарии и экраны, архитектуру рассчитываем под нагрузку и бюджет.
Код и тесты пишем одновременно, каждое изменение проходит проверку кода.
Все заявленные функции работают, список задач закрыт. Остается довести продукт до эксплуатации.
Проверяем, выдержит ли продукт реальную нагрузку, настраиваем мониторинг, смотрим безопасность и отказоустойчивость.
Разворачиваем продукт в рабочей среде. С релиза у продукта начинается обычная жизнь.
После запуска продукт меняется: исправляем ошибки, обновляем зависимости, добавляем функции. Поддержку и небольшие доработки ведем по абонентской плате.
Переносим данные, отключаем зависимости и проверяем, что ничего не потерялось. Вывод из эксплуатации планируем так же тщательно, как запуск.
Технологии, на которых собираем фронтенд
JavaScript
TypeScript
HTML
CSS
React
Next.js
Angular
Redux
Mobx
Pinia
Tailwind CSS
Vite
Webpack
Storybook
Material UI
Ant Design
С каких бюджетов начинаем работу
Ответим в течение рабочего дня
Уточним задачу и предложим формат работы
Подготовим оценку сроков и бюджета
Подберем состав команды под ваш стек
Если пришлете ссылку на макеты, рассчитаем точнее