Один и тот же макет из 8 экранов может стоить 60 часов как обычная верстка и 180+ часов как клиентская часть сервиса. Я вижу это регулярно: бизнес приходит с запросом "нужно просто сверстать по Figma", а через полчаса разговора выясняется, что там уже личный кабинет, роли, фильтры, формы, история действий и интеграция с CRM. В этот момент меняется не только смета, меняется сам тип проекта.
Такая путаница дорого обходится не из-за чьей-то жадности. Заказчик, дизайнер и разработчик часто по-разному понимают слово "верстка". Если упростить, здесь все сводится к одному вопросу: где заканчивается экран и начинается система.
Где кончается макет и начинается продукт
Мини-диалог, который у нас был не раз:
- "Нам нужна просто верстка сайта по Figma".
- "Есть личный кабинет, роли, фильтры, формы, CRM?"
- "Да, но это же потом подключится?"
- "Вот это 'потом' и есть основная часть работы".
Верстка - это HTML, CSS, адаптив, состояния элементов, базовая анимация, простые формы. Для лендинга или корпоративного сайта этого часто достаточно. Экран собрали, проверили на телефоне и десктопе, подключили к CMS - и проект живет.
Когда в проекте появляются авторизация, сохранение данных, статусы, работа с API, ошибки сервера и разные права доступа, начинается другая экономика. Внешне экран может почти не измениться, но внутри уже нужны клиентская логика, сервер, база данных и правила безопасности.
На проекте для EdTech в прошлом году мы делали лендинг и кабинет ученика параллельно. Лендинг занял 56 часов. Кабинет с уроками, прогрессом, валидацией и синхронизацией с API - еще 180 часов только на frontend, без сервера.
Цена растет из-за состояний, а не из-за страниц
Самая частая ошибка в оценке - считать экраны. На практике цену определяет число сценариев и состояний компонентов. Одна форма может жить в режимах: пустая, с ошибкой, с маской, с загрузкой, с серверным ответом, с блокировкой кнопки, с успешной отправкой. И все это еще должно работать на нескольких размерах экрана.
На продакшене сроки съедают не страницы, а состояния интерфейса.
Если в Figma этого нет, команда начинает проектировать поведение уже в коде. Мы однажды недооценили такой кабинет для B2B-логистики: дизайн был аккуратный, но без UI-kit и без повторного использования компонентов. В итоге фильтры, селекты и таблицы приходилось додумывать по ходу, и смета выросла на 38% еще до подключения сервера. Это как раз тот случай, где мы ошиблись в оценке не из-за объема экранов, а из-за недооценки системной части.
Для ориентира картина обычно такая:
| Сценарий | Что внутри | Оценка |
|---|---|---|
| Лендинг, 8 экранов | текст, изображения, простые формы | 40-80 часов |
| Корпоративный сайт, 4 шаблона | меню, адаптив, анимации, формы | 70-140 часов |
| Интерфейс сервиса, 8 экранов | таблицы, фильтры, роли, API | 120-250+ часов |
Системно это выглядит так:
экран -> компонент -> состояние -> сценарий -> данные -> интеграция.
Чем правее по этой цепочке проект, тем меньше смысла обсуждать его словом "верстка".
Почему одна строка в смете почти всегда выходит боком
Когда в смете написано "сайт под ключ", цифра выглядит удобно. Но внутри такой строки обычно смешаны интерфейс, CMS, клиентская логика, сервер, интеграции и тестирование. На старте это кажется экономией. По ходу проекта выясняется, что вы купили будущий спор о том, что именно входит в работу.
Мы предпочитаем раскладывать проект по слоям еще до договора:
- что живет в браузере
- что уходит на сервер
- что хранится в базе
- что собирается через CMS
- что надо тестировать отдельно
Такой разбор макета обычно занимает 4-8 часов и часто экономит 2-4 недели переделок. Особенно если проект потом будет развиваться, а не останется замороженным после первого релиза.
Кейс, где готовая верстка не помогла запуститься
У нас был проект в e-commerce. Команда после дизайна заказала только HTML-верстку за 120 тыс. ₽, а подключение логики решила оставить "на потом" через CMS и внешние API. План выглядел разумно, пока не началась сборка.
Формы не умели показывать ошибки сервера. На мобильном оформление заказа ломалось на шаге доставки. Часть компонентов не укладывалась в ограничения CMS. Корзину, кабинет и часть каталога пришлось переписывать уже после того, как работа вроде бы была сделана. Потеряли 5 недель и еще около 190 тыс. ₽. При этом 72% трафика было с мобильных устройств, и именно там просела конверсия.
Там же вылез второй слой проблемы - скорость. Когда LCP уходит дальше 2,5 сек, а отклик интерфейса плавает, хороший дизайн уже не спасает. Пользователь не думает, кто виноват - верстка, CMS или API. Он просто уходит.
Как считать такие проекты в ближайшие месяцы
Если проект хранит данные, меняет статусы, различает роли пользователей и обменивается данными с другими системами, его уже полезнее считать как сервис. Для него важны компоненты, сценарии, ограничения CMS, требования к SEO, скорость, доступность и структура данных. Количество экранов здесь дает слишком мало информации.
В ближайшие 6-12 месяцев рынок еще сильнее уйдет от оценки "по страницам" к оценке "по компонентам и сценариям". Поэтому перед следующей сметой попросите у подрядчика одну простую вещь: список того, что живет в браузере, на сервере и в базе. После этого обычно становится ясно, кто действительно считает проект, а кто просто умножает макеты на часы.
