Новые сайты — по вашему ТЗ, не на типовом шаблоне.
Новая разработка — это чистый лист, ваше ТЗ в таблице Google Sheets, и команда, которая делает по нему, а не пробует переделать вашу стратегию. Из Figma в продакшен. Никаких импровизаций в конструкторе.
Разработка с нуля — строго по ТЗ.
Новая разработка начинается там, где у вас уже есть ТЗ. Вы передаёте нам карту сайта, библиотеку Figma или прототипы, каталог шаблонов. Оценку часов по каждой строке мы заполняем сами — этот построчный бюджет и становится контрактом. Дальше строим по этому ТЗ: регистрируем шаблоны, подключаем страницы, выбираем и настраиваем плагины, разворачиваем хостинг-среду. Не принимаем за вас дизайн-решений, не пишем тексты. Всё, что увидит ваш клиент, — остаётся за вами.
Делаем в два этапа. На первом — собираем шаблоны и страницы (формальный уровень «страницы существуют»). На втором — доводим до уровня «можно сдавать клиенту»: согласуем внутренние ссылки, доводим контент, ловим баги из QA-циклов, обе очереди задач (разработки + от менеджера аккаунта) закрываем до нуля. Только после этого открываем чек-лист запуска.
Архитектура темы, свои Gutenberg-блоки или Elementor Pro, группы полей ACF, Gravity Forms или SaaS-виджеты бронирования, тестовая среда WP Engine или Kinsta → продакшен — инструменты подстраиваем под ваш стандартный стек. Что не подстраиваем: таблица Google Sheets — это контракт, столбец «Оценка часов» — это бюджет, а статус «Фаза 1 завершена» в трекере — это ещё не сдача проекта.
Ребилд заменяет существующий сайт строка за строкой: карта редиректов, спецификация мета-тегов, сохранение legacy URL. Новая разработка начинается с чистого URL-пространства — без отправной точки для миграции, без «позиций, которые нужно сохранить».
Доработка темы настраивает готовый фирменный шаблон под каждого клиента. Новая разработка создаёт страницы и шаблоны из вашей библиотеки Figma — ваша дизайн-система, ваша URL-архитектура, с нуля.
-
01
Приём таблицы Google Sheets и фиксация объёма работ
Открываем вашу таблицу Google Sheets — листы «Карта сайта», «Шаблоны», «Чек-лист», «QA-очереди» — и фиксируем объём работ до первой строки кода. У каждой строки карты сайта есть своя оценка часов; этот построчный бюджет — и есть контракт. Все неясности ловим на этом этапе, а не в середине разработки.
-
02
Регистрация шаблонов и настройка среды
Разворачиваем тестовую среду на вашей хостинг-платформе (WP Engine, Kinsta или ваш VPS). Регистрируем шаблоны — один PHP-файл или Elementor-шаблон на каждый тип из вашей библиотеки. Ставим и настраиваем стек плагинов: SEO, производительность, формы, виджеты бронирования. Никаких импровизированных дополнений.
-
03
Первичная разработка страниц по карте сайта
Делаем каждый URL карты сайта под назначенный шаблон и в его построчную оценку часов. На этом этапе подключаем свою логику под ваш проект — обычно ACF, кастомные типы записей, таксономии, структуру меню, интеграции плагинов. Контентные решения, видимые клиенту, остаются за агентством.
-
04
QA перед сдачей через Site Checker
Прежде чем открыть тестовую среду вашей QA-команде, прогоняем разработку через Site Checker — наш WordPress-плагин — по настройкам, контенту и SEO, структуре URL, языковой чистоте, меню, виджетам и скриншотам в разных разрешениях. Порог: ноль провалов. Предупреждения смотрим вручную и признаём некритическими до передачи.
-
05
Параллельные QA-циклы, доводимые до нуля
Параллельно идут две очереди задач: одна по разработке (проблемы реализации, баги шаблонов, сбои интеграций) и от менеджера аккаунта или клиентского опыта (тексты, вёрстка, UX-наблюдения от вашей команды). Обе закрываем до нуля. Только после этого открываем чек-лист запуска — с открытыми задачами разработки не запускаем.
-
06
Подписание чек-листа запуска и передача
Чек-лист запуска — столбцы «Дизайн», «Функциональность», «До запуска» и «После запуска» — подписываем строка за строкой. После закрытия чек-листа сайт ваш: тестовая среда готова к выкладке в продакшен, агентский QA-слой закрыт, никаких хвостов. После сдачи мы не пишем тексты и не принимаем за вас дизайн-решений.
- Количество страниц 15–120 URL по карте сайта, каждый на своём шаблоне в рамках построчного бюджета часов; в консолидации нескольких филиалов может быть больше
- Шаблоны 5–12 повторно используемых шаблонов, зарегистрированных из вашей библиотеки Figma — PHP темы, свои Gutenberg-блоки или Elementor Pro по вашему стеку
- Своя логика Группы полей ACF, кастомные типы записей, таксономии, структура меню, интеграции плагинов — состав зависит от проекта
- Сроки 20–130 дней на однофазной разработке при обычном ритме ваших проверок; до 200+ дней с фазой согласования или при долгих циклах ответов клиента. Календарь зависит от темпа ревью на вашей стороне — бюджет часов мы держим в любом случае.
- Трудозатраты 25–170 часов типично: разработка + QA-итерации + управление проектом, привязанные к построчной оценке часов в таблице Google Sheets; сложные разработки с консолидацией нескольких филиалов могут быть выше
- Команда 3–6 специалистов — ведущий разработчик, QA-специалист, руководитель проекта, плюс дополнительная поддержка разработки или контента в крупных проектах
- Хостинг По умолчанию — ваш хостинг (WP Engine, Kinsta или ваш VPS). Можем поднять тестовую среду у нас — это редко, обычно под конкретные внутренние задачи.
- URL тестовой среды Настраиваем на вашем хостинге в течение недели от старта; открываем для QA-команды после того, как Site Checker проходит без провалов
- Контрольные точки QA Site Checker без провалов до передачи + параллельные очереди задач (одна по разработке, одна по проверке) — обе закрываем до нуля перед запуском
Разработки от портфолио.
White-label проекты, выполненные для американских маркетинговых агентств. Конечные клиенты названы с разрешения; партнёрские агентства не называются.
Что определяет бюджет часов.
Чтобы бюджет не плавал, считаем его построчно — никаких прикидок «в целом по проекту». В таблице Google Sheets каждой странице — свой бюджет часов. Сумма строк — это и есть контракт. Ниже — факторы, которые сдвигают итоговую сумму, на примерах реальных проектов.
Однолокационная, однофазная разработка на готовой системе шаблонов. Простые интеграции форм, стандартная структура меню. QA-хвост короче.
Многофилиальная маршрутизация, виджеты бронирования для каждой локации или большая матрица услуг/процедур. Чем больше локаций — тем длиннее QA-хвост: каждая локация множит объём проверки. Реальный пример: 138 ч на 3 локации, 33 процедуры, 47 URL.
Два или более legacy-домена сводим в один новый брендовый сайт. Пары редиректов с каждого legacy-домена добавляют слой согласования внутренних ссылок поверх стандартного объёма работ. Импорт блог-корпуса (100+ постов) — главный драйвер бюджета в этой форме: время уходит на контент-импорт, а не на уникальную вёрстку.
Когда бренд-система агентства ещё дорабатывается, а сайт нужен сейчас. Делаем в два захода. Первый: собираем сайт по текущим дизайн-материалам и закрываем разработку. Второй: обновляем визуал под финальную бренд-систему, когда она у вас готова. Часы обоих заходов заложены в смету заранее — итоговый бюджет не растёт, но между фазами есть пауза, поэтому календарь длиннее однофазной разработки.
3–6 человек на проект — зависит от количества страниц, глубины своей логики и объёма QA. Доля QA меняется по форме: в многофилиальной разработке хвост правок и обратной связи может занимать 50–60% часов; в однофазной с готовой системой шаблонов — ближе к 20–30%. Доля PM высокая в двухфазных (координация на обоих этапах), низкая в однофазных, где таблица Google Sheets берёт координацию на себя.
Часто спрашивают, отвечаем прямо.
По этому формату: что под ним понимаем, что берём на себя и что влияет на часы.
-
По каждой строке вашей карты сайта. Колонку «Оценка часов» мы заполняем сами строка за строкой до старта — каждая страница или шаблон получает свою оценку, в сумме это и есть смета проекта. В ходе разработки трекаем факт по каждой странице против этих построчных оценок — отклонения ловим заранее, а не при сдаче. Если строка выходит за план (тяжёлая миграция контента, неучтённая интеграция форм), пишем вам в течение рабочей недели с переоценкой, до того как отклонение накопится.
-
Это признанный формат, не обходной путь. Этап 1 (первичная разработка по карте сайта) и Этап 2 (согласование дизайна с брендовой системой) у нас — две отдельные сдачи, каждая со своим QA-барьером. Считать Этап 1 «сборкой завершённой» до согласования — именно та ошибка, от которой этот процесс защищает.
-
Обе. Двухнаправленная структура неизменна — названия варьируются по агентствам (SEO + AM, Issues + AM Issues, DEV + CX), — но запуск только когда обе очереди достигают согласованного порога. Site Checker мы прогоняем до открытия любой из очередей — ваша QA-команда никогда не начинает на недоделанной тестовой среде.
-
Да, существенно. На недавней миграции блога ~130 постов мы потратили 89,5 часов на эту одну строку таблицы Google Sheets — больше, чем все часы разработки по проекту (75 часов в Redmine). Строку блога выделяем в таблице отдельным суббюджетом, не сворачивая её в общий счёт страниц.
-
Зависит от формата. Двухфазная многосторонняя разработка с согласованием брендовой системы может давать до ~46% часов PM — это самые сложные по координации проекты, которые мы вели. Однофазная с импортом контента — 10–12%. До сметы говорим, к какому из этих форматов ближе ваше ТЗ. В однофазной разработке можно честно обещать минимум координации; в двухфазной — координация неизбежна, и пытаться выдавать её за минимум было бы нечестно.
Есть
готовое ТЗ?
Пришлите файл Figma, таблицу Google Sheets с картой сайта или описание объёма работ в одном абзаце. В течение 24 часов: чёткий набор уточняющих вопросов и фиксированная оценка часов по вашему построчному бюджету. NDA по запросу до того, как мы откроем любые материалы.
Не уверены, подходит ли вам новая разработка? Сравнить с ребилдом →