«Нам нужен просто сайт» - фраза, после которой у меня почти всегда всплывают роли, личный кабинет, оплаты, CRM и длинные сценарии. Через 3-6 недель после старта разговор обычно уже другой: почему правка тянется 5 дней, почему каталог тормозит на телефоне, почему одна форма ломает соседний экран.
Я не вижу смысла спорить о технологиях в отрыве от задачи. Разница между сайтом и продуктом - в сценариях, данных и цене будущих изменений. Если не разложить это в начале, переплата почти неизбежна.
«Просто сайт» заканчивается очень быстро
HTML и адаптивная верстка - это база. Но если путь пользователя длиннее 3 шагов, данные приходят по API, а интерфейс зависит от роли, это уже не набор страниц. Это веб-приложение, даже если внутри компании его по-прежнему называют «сайтом».
У нас был клиент из оптовой торговли. Он пришел с ожиданием уложиться в 350 тыс. ₽ на «обновление сайта». На первом созвоне выяснилось, что нужны каталог с фильтрами, кабинет дилера, цены по сегментам, статусы заказов, интеграция с amoCRM и выгрузка остатков. После декомпозиции бюджет стал ближе к 1,4 млн ₽.
Мини-диалог был вполне типовой:
- Нам нужен обычный сайт.
- Личный кабинет будет?
- Да, и роли для менеджеров, и онлайн-оплата.
- Значит, это уже другой класс проекта.
Люди держатся за слово «сайт», потому что оно звучит дешевле и спокойнее. Код от этого дешевле не становится.
Модный стек сам себя не окупает
В прошлом году мы забирали корпоративный проект после команды, которая собрала все как SPA на React «на вырост». На презентации это звучало убедительно. На практике мобильная версия грузилась хуже, редакторы не могли нормально править контент, SEO-страницы просели по индексации.
Мы перевели ключевые разделы на Next.js 15 с SSR и SSG. За 8 недель получили LCP лучше на 34% и рост органики на 18%. Не потому что React плохой, а потому что стек не совпал с задачей.
| Формат | Где работает нормально | Что получает бизнес | Где обычно идет переплата |
|---|---|---|---|
| Статический сайт | лендинг, промо | быстрый запуск, низкий чек | когда потом добавляют кабинет |
| SSR/SSG | каталог, SEO, медиа | лучше скорость и индексация | когда нет нормальной CMS |
| SPA | CRM, SaaS, личный кабинет | гибкий интерфейс | когда так делают маркетинг-сайт |
Для сложных интерфейсов мы обычно берем TypeScript + React + Next.js. Дальше смотрим по задаче: TanStack Query - для работы с серверными данными, Zustand - для умеренного состояния, Redux Toolkit - когда ролей и сценариев уже много. Для промо-сайта я бы не стал тянуть этот набор без причины.
Экономия начинается после релиза
Самый дорогой frontend я видел там, где не было системы. В одном B2B SaaS после первого релиза на React 18 мы нашли 47 почти одинаковых таблиц и 19 вариантов модальных окон. Визуально все выглядело нормально, внутри был хаос.
Мы собрали UI-kit, вынесли паттерны в Storybook, договорились о правилах состояния через TanStack Query и Zustand. Через 6 недель типовой экран делали уже за 1-2 дня вместо 3-4 дней.
CTO логистической платформы хорошо это сформулировал: «Пользователь не видит архитектуру. Он видит медленные таблицы и странные ограничения».
У меня был и обратный случай. На одном контентном проекте мы слишком рано начали строить тяжелую дизайн-систему, хотя у клиента было всего 12 шаблонов страниц и редкие изменения. Потратили лишние 3 недели, а ценности это не дало. Система нужна там, где у продукта есть повторяемость и рост, а не просто планы «на будущее».
Сроки ломаются на стыке frontend и backend
Когда бизнес говорит, что «фронт тормозит», причина часто в связке слоев. У нас был кабинет сервисной компании: таблицы зависали, фильтры дергались, менеджеры уже требовали менять frontend-команду. Разобрали цепочку и увидели, что backend на Laravel 11 отдавал тяжелые ответы без пагинации и с лишними полями.
После пересборки контрактов через OpenAPI и введения BFF время ответа ключевого экрана упало с 2,8 сек до 700 мс. Клиент собирался лечить интерфейс, а проблема сидела глубже.
UI -> BFF/API -> backend -> база данных
Если в этой цепочке нет договоренностей по структуре ответов, ошибкам, правам и пагинации, frontend почти всегда будет дорогим. Я видел это десятки раз.
Что спросить до старта, чтобы не купить лишнее
На первой встрече мне обычно хватает 20-30 минут, чтобы понять класс проекта. Не по стеку, а по сценариям. Если подрядчик начинает разговор с любимого фреймворка, а не с логики продукта, я бы напрягся.
Я бы задал пять прямых вопросов:
- Где заканчивается верстка и начинается продуктовая логика
- Почему выбран этот стек и что будет дорого менять через 6 месяцев
- Как решены SEO, мобильная скорость и редактура контента
- Кто отвечает за контракт между frontend и backend
- Что сломается первым при добавлении новой роли или оплаты
Если в начале вам продают «просто сайт», почти наверняка через месяц начнутся разговоры про архитектуру, API и производительность. Я бы предпочел обсудить это сразу, чем потом возвращаться к тому, что было понятно еще на первом разговоре.
