На входе это часто звучит одинаково: «у нас уже есть дизайн, надо просто собрать сайт». Я вижу такие проекты постоянно. На экране все и правда выглядит почти готовым, но после пары интервью всплывают роли, статусы, история действий, оплаты, документы и обмен с CRM. В этот момент смета считается уже не по количеству экранов, а по правилам, данным и интеграциям.
Недавно к нам пришел проект с 18 экранами в Figma. Через два созвона выяснилось, что менеджер видит только свои заявки, руководитель - все, клиенту нужен статус работ, бухгалтерии - оплаты и акты, а еще нужна связка с amoCRM. Визуально это все еще сайт, но по сути - уже создание веб-приложения.
Один экран для бизнеса - три слоя для команды
Для владельца бизнеса это одна сущность: страница, форма, кнопка. В разработке почти всегда есть 3 слоя: интерфейс, логика и данные. Поэтому верстка сайта редко покрывает весь проект, даже если макеты выглядят законченными.
HTML-верстка и адаптивная верстка отвечают за структуру, стили, мобильные состояния и поведение блоков на разных экранах. Это важная часть проекта, но она не решает авторизацию, права доступа, хранение заявок, оплату и создание веб-сервисов для обмена с внешними системами.
У нас был интернет-магазин, который стартовал как «каталог + корзина». После интервью добавились остатки по складам, резервирование товара, личный кабинет и обмен с 1С. В такой конфигурации backend-разработка заняла около 60% работ, хотя на старте клиент был уверен, что главное уже нарисовано.
Быстрый чек-лист здесь простой:
- есть личный кабинет
- есть разные роли пользователей
- нужны оплаты, статусы или документы
- есть интеграции с CRM, 1С или ERP
- нужна админка с управлением данными
Если совпало 3 пункта и больше, я сразу оцениваю проект как приложение, а не как набор страниц.
Frontend начинается там, где экран живет по правилам
Frontend-разработка начинается не в тот момент, когда подключили React, а когда интерфейс должен что-то решать сам: проверять форму до отправки, держать состояние фильтров, показывать ошибки, сохранять черновики, работать с API без перезагрузки страницы.
В B2B-кабинете для отдела продаж мы вынесли часть проверок на клиентскую сторону: лимиты, обязательные поля, автоподстановку реквизитов. Это заняло 2 недели, но ошибки в формах упали на 30%, а время заполнения - на 22%. Стек был обычный для таких задач: TypeScript, React 19, Next.js 15, REST API.
| Что делает верстка | Что делает frontend |
|---|---|
| структура страницы, стили, адаптивность | состояние интерфейса, формы, маршруты |
| отображение готовых данных | запросы к API, обработка ошибок |
| базовые анимации | авторизация на клиенте, черновики |
Граница тут видна довольно быстро:
fetch('/api/orders')
.then(res => res.json())
.then(data => {
renderOrders(data)
updateCounter(data.length)
})
.catch(() => showError('Не удалось загрузить заказы'))
Верстка рисует список. Frontend получает данные, обновляет экран и показывает, что пошло не так.
Backend - там, где система принимает решения
Backend-разработка нужна в тот момент, когда у бизнеса появляются правила: кто что видит, кто может менять статус, когда отправлять уведомление, что делать при повторной оплате, как хранить историю действий. На деле именно здесь рождается большая часть сроков.
Сюда же относится создание базы данных веб-приложения. Это не «завести пару таблиц», а решить, какие сущности связаны между собой, где нужны ограничения, какие запросы будут частыми и как потом строить отчеты. Если ошибиться здесь, проект сначала работает терпимо, а потом начинает тормозить в самый неподходящий момент.
У нас был сервис бронирования на Laravel 11 и PostgreSQL 16. До 50 000 записей все выглядело нормально, потом подбор слотов вырос до 4-6 секунд. Мы переделали схему БД, добавили составные индексы, кеширование на Redis 7.2 и разнесли тяжелые операции по очередям. Выборки ускорились в 5-8 раз, а пиковая нагрузка на базу снизилась на 37%.
Срывы по срокам обычно начинаются там, где на старте недооценили бизнес-правила, API и интеграции.
Дешевый старт часто делает дорогую переделку
MVP я люблю и сам так запускаю проекты. Экономить лучше на объеме первой версии, а не на структуре данных и серверной логике. Это разные вещи, и бизнес часто путает их между собой.
В прошлом году у нас был проект, который стартовал как WordPress-сайт с формой заявки. Через 4 месяца понадобились кабинеты клиентов, история операций и интеграция с 1С. Из-за того что данные хранились как попало, а API вообще не планировался, доработка вышла дороже примерно на 25-35%, чем если бы мы сразу заложили backend на Node.js 20 + NestJS.
У нас был и неудачный опыт. Несколько лет назад мы согласились оставить часть бизнес-правил в JavaScript на фронтенде, потому что клиент торопился. Через пару релизов логика на экране и на сервере разъехалась, и менеджеры получали разные результаты в похожих сценариях. С тех пор такие вещи мы фиксируем сразу: проверка на клиенте помогает пользователю, но источник истины живет на сервере.
Нормальная оценка начинается с вопросов, а не со стека
Если подрядчик говорит «сделаем 10 экранов за 2 недели», а у вас есть платежи, журнал действий, роли и CRM-интеграция, я бы насторожился. Экранов может быть мало, а работы под ними - совсем не мало.
Мы обычно тратим 1-2 недели только на декомпозицию, даже если дизайн уже готов. Это не попытка растянуть проект. Пока не описаны роли, сценарии, структура данных и точки обмена, честной сметы не будет.
Я сам не раз ошибался в ранних оценках, когда заказчик приносил «просто сайт», а внутри оказывался внутренний сервис для половины компании. Поэтому мой совет простой: перед первым созвоном опишите не страницы, а действия - кто входит, что видит, что меняет, какие данные хранит и куда они уходят. Самая дорогая часть проекта обычно спрятана не в дизайне, а под кнопкой «Сохранить».
