У «вёрстки под ключ» нет одного обязательного состава — до заказа нужно уточнить, получите ли вы код, установленную страницу или опубликованный сайт с проверенными подключениями
В предложении может быть одна короткая строка, а у участников — разные ожидания
Заказчик ждёт страницу на домене, дизайнер считает работу законченной после макетов, разработчик готовит архив с кодом — каждый может выполнить свою часть и всё равно не получить общий результат
Разберём, как расшифровать формулировку «под ключ» и распределить ответственность до начала работы
Назовите конечный результат
Начните с того, что должно появиться у вас после завершения
Это может быть комплект вёрстки для своей команды, страница в действующей системе управления или работающая публичная версия
Ни один из вариантов не является плохим сам по себе — важно, чтобы предложение описывало именно тот, который нужен вам
| Результат | Что передаёт исполнитель | Что ещё может понадобиться |
|---|---|---|
| Комплект вёрстки | Исходники, ресурсы и согласованная сборка | Подключение к системе и публикация |
| Страница в действующей CMS | Реализованный шаблон и способ редактирования | Проверка внешних сервисов и рабочей среды |
| Опубликованная версия | Страница по публичному адресу и результаты проверок | Поддержка и дальнейшие изменения по отдельным условиям |
CMS — система, через которую сотрудники меняют содержание сайта
Если своей технической команды нет, выясните, кто возьмёт оставшиеся задачи — обещание «передадим готовый код» не назначает такого человека автоматически

Отделите интерфейс от обработки данных
В интерфейсе можно показать каталог, форму, оплату и личный кабинет — это ещё не означает, что системы за ними созданы и подключены
Для формы нужно определить получателя данных, обработку ошибки и способ проверки доставки
Для каталога — источник содержимого и обновления, для кабинета — правила доступа, для оплаты — выбранный сервис и ответственного за интеграцию
Внешний вид и поведение элементов обсуждаются вместе с этими зависимостями, но не заменяют их
Проверка полей в браузере не заменяет серверную — это отмечено в руководстве MDN
О составе самой услуги можно прочитать в отдельном объяснении вёрстки
Что уточнить по содержанию
Зафиксируйте, кто предоставляет тексты, изображения, документы и данные каталога
Если работа начинается с примерного содержания, нужно предусмотреть проверку после заполнения — длинные названия и реальные абзацы могут изменить расположение блоков
Проверьте права на используемые материалы и условия выбранных платных сервисов
Укажите, кто в дальнейшем будет менять содержание и какой способ редактирования ему нужен — это помогает выбрать подходящий формат передачи
Как описать обязанности без общих слов
Представим учебный заказ: сайт уже работает на CMS, новый макет страницы услуги готов, но форму нужно связать с существующей системой обращений
В проекте участвуют заказчик, верстальщик и разработчик действующего сайта — слова «всё под ключ» не объясняют, кто из них будет устанавливать шаблон
Вот как может выглядеть заполненный список ответственности для этой ситуации
| Работа | Исполнитель в примере | Что принимает заказчик |
|---|---|---|
| Финальные тексты и фотографии | Маркетолог заказчика | Одна папка материалов и утверждённый макет |
| Страница и мобильное меню | Верстальщик | Версия в браузере, в которой открываются меню и ответы на вопросы |
| Установка шаблона в CMS | Разработчик действующего сайта | Текст и изображение меняются через редактор без правки кода |
| Подключение формы | Тот же разработчик | Тестовое обращение появилось в выбранной системе, посетитель увидел подтверждение |
| Размещение на домене | Разработчик действующего сайта | Открывается нужный URL, работает скачивание, форма повторно проверена |
| Приёмка и замечания | Маркетолог заказчика | Общий список с проверенными исправлениями и оставшимися вопросами |
Такая таблица сразу обнаруживает разрыв: если разработчик действующего сайта не участвует, установка, форма и публикация пока никому не поручены — готовая вёрстка сама этот пробел не закрывает
До начала работы можно выбрать один из двух путей: включить недостающие задачи в предложение выбранного исполнителя или найти участника, который их возьмёт
Для своего проекта замените названия ролей конкретными участниками — если строка остаётся без исполнителя, сохраните её как открытый вопрос, а не как готовую часть заказа
Проверки доступности тоже стоит распределить: W3C рекомендует назначать ответственных и включать оценку в работу над сайтом в руководстве по планированию
Почему запуск стоит выделить в отдельный пункт
Работающая тестовая версия не всегда означает готовность на основном домене
Могут отличаться пути к файлам, настройки HTTPS, доступность внешних сервисов и параметры аналитики
Перед размещением определите, кто сохраняет предыдущую версию, кто переключает сайт и кто проходит проверку уже после выпуска
Если меняются адреса существующих страниц, нужен отдельный план соответствий и перенаправлений — рекомендации Google приведены в руководстве по смене URL
Для нового лендинга состав запуска разобран в статье об оценке вёрстки лендинга
Что получить вместе с результатом
Следующий разработчик должен получить редактируемые файлы проекта, используемые изображения и шрифты, инструкцию запуска и перечень подключённых сервисов — например, редактор содержания и сервис получения обращений
Попросите принимающую команду открыть переданную версию по инструкции — если для запуска требуется неизвестный аккаунт или отсутствующий файл, передача ещё не завершена
У готовой сборки для размещения и исходников для изменений разные роли — оба комплекта должны относиться к одной принятой версии, иначе на домене окажется одно, а в работе у команды другое
Сотруднику, который будет менять содержание через редактор, предложите самостоятельно заменить текст на тестовой странице — так станет видно, хватает ли ему инструкции и прав
Аккаунты сервисов тоже требуют передачи: у заказчика должен остаться доступ, который позволит продолжить работу после ухода временного исполнителя
Не включайте пароли и токены в открытый бриф или публичную инструкцию
Зафиксируйте, как сообщать об ошибках, какие исправления входят в условия и как согласуются новые задачи — поддержка не становится бессрочной только из-за слов «под ключ»
Самопроверка предложения
Отметьте, какие вопросы уже закрыты в обсуждении — список покажет, что ещё стоит уточнить
Отметки помогают найти пробелы в договорённостях, но не подтверждают работоспособность сайта — для этого нужно пройти приёмку
Как сравнить стоимость
Сопоставьте одинаковый результат: если один вариант заканчивается передачей кода, а другой включает установку и выпуск, итоговые суммы описывают разный объём
Добавьте работы вашей команды и необходимые внешние расходы, чтобы увидеть общий состав
Попросите перечислить предположения и неизвестные условия — подробнее этот подход разобран в статье о стоимости вёрстки
Порядок вопросов к исполнителю есть в гайде о заказе по макету
Что предлагает KEIVO
Основа услуги вёрстки KEIVO — реализация согласованного интерфейса по макету, адаптивы, состояния и проверка результата
Установку в CMS, обработку формы и подключение оплаты обсуждаем отдельно от реализации интерфейса
Можно скачать бриф и отметить нужные части вашего проекта — приём заявок на новой странице пока не открыт
Вопросы о формулировке «под ключ»
Под ключ всегда означает публикацию на домене?
Это нужно проверить в составе предложения — формулировка сама по себе не определяет обязанности исполнителя и формат передачи
Можно оставить подключения своей команде?
Да, если ответственные, формат передачи и проверка стыка между работами согласованы — важно, чтобы нужная часть не осталась без исполнителя
Нужно ли включать всё в один заказ?
Не обязательно — можно разделить работы, если конечный результат, зависимости и порядок приёмки остаются понятными
Источники и границы
Источники проверены 29 октября 2026 года — таблица ответственности и вопросы подготовлены редакцией KEIVO