Выбирайте разработчика сайта по подтверждённому опыту, понятному составу работ, критериям приёмки и условиям дальнейшей работы. Сравнение цен становится полезным, когда подрядчики оценивают одинаковые страницы, функции, материалы и интеграции.
У двух предложений с формулировкой «корпоративный сайт под ключ» может оказаться разный результат. В одном предусмотрены структура, тексты, наполнение и обработка заявок. В другом — сборка страниц по готовым материалам заказчика. Чтобы выбрать веб-студию или независимого разработчика, сначала нужно раскрыть эти различия.
Ниже — практический порядок сравнения: от короткого задания до демонстрации готового сайта. Вопросы и таблицу можно использовать при общении с любым подрядчиком.
1. Опишите задачу, которую должны оценить все кандидаты
Начните с действий клиента и команды. Например, компания продаёт оборудование: посетитель находит подходящую модель, прикладывает схему подключения и отправляет запрос. Менеджер получает обращение вместе с названием товара и вложением, отвечает клиенту и меняет статус заявки. Это условный пример для сравнения предложений, а не результат конкретного проекта.
Для такой задачи фраза «каталог и форма» оставляет много вопросов. Кто загружает товары? Можно ли выбрать параметры? Где сохраняется обращение? Что увидит клиент, если файл не загрузился? Нужна ли связь с CRM?
Подготовьте один документ для всех кандидатов:
- Цель: какое действие посетителя и какой результат работы команды нужны бизнесу.
- Структура: предполагаемые разделы, типы страниц и основные пользовательские сценарии.
- Материалы: какие тексты, фотографии и данные уже есть, кто готовит недостающее.
- Связанные системы: CRM, учётная программа, оплата, доставка и другие реальные зависимости.
- Ограничения: нужная дата запуска, доступность сотрудников, ориентир бюджета и обязательные функции первой версии.
- Проверка результата: что вы хотите самостоятельно выполнить на демонстрации.
Не обязательно заранее знать техническое решение. Отметьте неизвестное: например, формат выгрузки каталога ещё предстоит выяснить. Тогда подрядчик сможет выделить обследование или прототип в самостоятельный этап и объяснить, после чего уточнится оценка.
Для подробной подготовки есть отдельный материал «Как подготовить задание на сайт».
2. Приведите коммерческие предложения к одному составу
Попросите каждого кандидата заполнить одинаковый перечень. Для каждой строки нужны результат, исполнитель, способ проверки и пометка: «включено», «отдельная оценка» или «не требуется».
| Что сравниваем | Какой результат уточнить | Что спросить у подрядчика |
|---|---|---|
| Структура и прототип | Карта разделов и основные сценарии | Какие страницы и состояния входят? |
| Дизайн | Макеты согласованных типов страниц | Как сайт проверяют на телефоне, что происходит с длинными текстами и ошибками? |
| Контент | Тексты, изображения и заполненные записи | Кто готовит и загружает материалы, какой объём включён? |
| Управление | Работа редактора с реальными записями | Что сотрудник сможет изменить самостоятельно? |
| Заявки и интеграции | Обращение доходит до согласованной системы | Где оно сохраняется и как виден сбой передачи? |
| Подготовка к поиску | Доступные страницы и согласованные метаданные | Входит ли перенос старых адресов, кто проверяет индексационные настройки? |
| Запуск и передача | Работающий сайт и комплект доступов | Кто публикует сайт, обучает редактора и передаёт инструкции? |
| Эксплуатация | Понятный порядок обновлений и обращений | Что оплачивается регулярно, кто отвечает после запуска? |
Особенно внимательно смотрите на слова «до», «от» и «при наличии готовых материалов». Сами по себе они не означают проблему: за ними могут стоять разумные ограничения. Попросите раскрыть, к какому объёму и условиям относится оценка.
Сравнивайте отдельно разовую разработку и регулярные расходы: платформу, хостинг, внешние сервисы, сопровождение. Неизвестную интеграцию оставляйте отдельной строкой с порядком уточнения. Сумма с несколькими неподтверждёнными допущениями ещё не является сопоставимой итоговой сметой.
Уточните модель расчёта: фиксированная цена за согласованный объём или оплата фактических часов. Во втором случае спросите о ставках, отчёте о выполненном и лимите бюджета. Для обоих вариантов зафиксируйте этапы оплаты и порядок предварительного согласования дополнительных расходов. Предложение с фиксированным составом и открытый почасовой бюджет требуют разного контроля.
О составе стоимости подробнее — «Сколько стоит корпоративный сайт и что входит в смету».
3. Проверьте в портфолио нужный вам сценарий
Попросите показать опубликованный проект, объяснить роль команды и пройти действие, похожее на вашу задачу. Для витрины это может быть выбор товара и переход к покупке. Для сайта услуг — поиск направления и отправка обращения. Для платформы — работа пользователя после входа.
Важен состав выполненной работы: подрядчик мог создать только дизайн, отдельную интеграцию или весь продукт. При закрытом доступе можно обсудить согласованную демонстрацию или обезличенный сценарий; отсутствие доступа ко всем внутренним экранам само по себе ничего не доказывает.
В опубликованном портфолио DDRW эти различия можно увидеть на конкретных примерах:
- Get Beauty: в кейсе описана витрина косметического бренда с переходами «Купить» на Wildberries. При сравнении похожего проекта нужно выяснить, требуется ли собственное оформление заказа или переход на внешнюю площадку.
- АНТА: описаны каталог направлений и обращение с описанием задачи и вложением. Для похожего сайта отдельно оценивают структуру услуг, контекст заявки и работу с файлами.
- Meetki: кейс посвящён связанному циклу встреч, результатов и следующих действий. Для подобной платформы нужно обсуждать состояния, роли и связи между записями, которые не видны по одному главному экрану.
Эти примеры помогают сравнить устройство продуктов и объём задач. Указанные кейсы не дают основания обещать такой же бюджет, рост продаж или одинаковый срок для другого проекта.
Если кандидат приводит коммерческие результаты, уточните период, источник данных и собственный вклад команды. Отдельная цифра без методики не показывает, что произошло благодаря разработке сайта.
4. Задайте разработчику 12 вопросов до выбора
Ответы удобнее сохранить в одном документе рядом со сметой. Хороший ответ содержит пример, результат или порядок действий, который можно проверить.
- Как вы поняли нашу задачу? Попросите описать путь клиента и работу сотрудника после обращения.
- Что входит в первую версию? Уточните страницы, функции, состояния и то, что сознательно отложено.
- На каких допущениях основана оценка? Выясните, какие данные, доступы и решения заказчик должен предоставить.
- Что именно вы сделали в похожем проекте? Попросите показать соответствующую часть работы.
- Кто принимает решения и ведёт проект? Должны быть понятны ответственный, канал общения и порядок согласования.
- Как выглядят промежуточные результаты? Уточните, когда можно увидеть структуру, прототип и рабочий сценарий.
- Кто готовит содержание? Разделите написание текста, подбор фотографий, обработку и загрузку материалов.
- Как сотрудник будет управлять сайтом? Попросите показать изменение услуги, изображения или товара в редакторе.
- Как проверяются интеграции и ошибки? Обсудите отказ внешнего сервиса, повтор обращения и неполные данные.
- Как согласуются изменения задачи? Нужно понимать, когда пересчитываются объём, срок и стоимость.
- Что передаётся при завершении? Перечислите доступы, материалы, инструкции и доступные способы выгрузки данных.
- Что происходит после запуска? Уточните, куда сообщать о проблеме, часы поддержки и границы исправлений и новых работ.
Технический термин сам по себе не отвечает на вопрос о качестве. Попросите объяснить, как выбранное решение связано с вашей задачей и как команда сможет его поддерживать. В руководстве GOV.UK по выбору технологий среди важных факторов рассматриваются совокупная стоимость владения, контроль данных и возможность менять решение по мере развития потребностей.
5. Свяжите каждый этап с проверяемым результатом
До старта договоритесь, что будет показано на каждом этапе и кто со стороны заказчика принимает решение. Формулировка «дизайн готов» становится понятнее, если известно, какие типы страниц и состояния согласованы. Уточнение «форма работает» требует пройти путь обращения до места, где с ним работает сотрудник.
Для рабочей версии сайта согласуйте короткий маршрут проверки:
Открываем страницу услуги на телефоне → заполняем обращение с вложением → видим подтверждение → находим обращение в согласованном интерфейсе → проверяем сохранённый контекст услуги и файл.
Дополнительно пройдите ошибку заполнения, повторное нажатие и временную недоступность связанной системы. Нужный набор зависит от проекта; согласуйте его заранее, чтобы приёмка не превратилась в бесконечное добавление новых требований.
Скорость тоже требует условий измерения: какие страницы, устройство, сеть и инструмент использовались. Google Web Vitals выделяет загрузку, отзывчивость и визуальную стабильность через LCP, INP и CLS. Попросите различать лабораторные проверки и данные реальных посещений; один балл без описания условий трудно использовать для приёмки.
Проверьте подписи полей, видимый фокус клавиатуры, читаемость и работу при увеличении текста. Первичные проверки W3C WAI помогают начать оценку доступности, но не заменяют полную проверку.
Результатом этапа должны стать доступная демонстрация, список согласованных замечаний и понятное решение о следующем шаге. Сам перечень проверок удобно дополнить чек-листом приёмки сайта.
6. Проверьте управление сайтом и комплект передачи
Попросите показать административную часть до завершения проекта. Выберите обычную задачу: заменить фотографию, добавить услугу, исправить текст или посмотреть новую заявку. Пусть будущий редактор выполнит её сам по инструкции. Такая демонстрация полезнее перечня возможностей CMS.
Составьте перечень того, чем команда должна управлять после запуска:
- Домен и инфраструктура: где находятся кабинеты управления, кто контролирует оплату и восстановление доступа.
- Сайт и материалы: какие макеты, файлы, исходный код доработок и инструкции входят в передачу.
- Данные: как выгрузить содержание и обращения, что входит в резервную копию и как предусмотрено восстановление.
- Аналитика и внешние сервисы: кто владеет рабочими аккаунтами и выдаёт доступ сотрудникам.
- Поддержка: ответственный, канал обращения, порядок обновлений и дальнейших изменений.
Уточняйте особенности выбранной платформы отдельно. Возможность редактировать страницы, экспортировать данные и перенести сайт в другую среду — разные свойства. Не предполагайте, что доступ к редактору автоматически даёт все остальные возможности.
Доступы сотрудникам выдавайте персонально и с необходимыми правами. Пароли и закрытые ключи передавайте защищённым способом; перечень кабинетов можно хранить отдельно от самих секретов. Дополнительные вопросы эксплуатации разобраны в материале о поддержке сайта после запуска.
7. Примите решение по фактам и открытым вопросам
Перед выбором отметьте, что подтверждено, а что ещё требует проверки. У вас должны быть сопоставимый состав, подходящий пример работы, понятные этапы, критерии приёмки и комплект передачи.
Повод для дополнительного обсуждения — одинаковая оценка для любых задач без вопросов, портфолио без объяснения участия, закрытая до финала демонстрация или отсутствие ответа о регулярных расходах. Попросите конкретику. По содержанию ответа станет понятнее, можно ли двигаться дальше.
Обещания гарантированного первого места в поиске рассматривайте отдельно от разработки. Google Search Central при выборе SEO-специалиста рекомендует проверять прошлые работы и настороженно относиться к гарантии первой позиции. В проекте сайта полезно фиксировать конкретные технические работы, содержание и способ последующей оценки.
Если значительная часть задачи пока неизвестна, начните с ограниченного этапа: обследования, структуры или прототипа нужного сценария. Его результат и состав передачи тоже должны быть определены. Он помогает уточнить дальнейшую разработку; обязательство продолжать весь проект с той же командой не стоит подразумевать молча.
Шаблон запроса для сравнения предложений
Нужен сайт для [компания и аудитория]. Основной сценарий: [действие клиента и результат для сотрудника]. В первую версию включаем [разделы и функции]. Уже есть [материалы и данные]. Нужно уточнить [интеграции и ограничения]. Просим отдельно описать состав работ, допущения, этапы, критерии приёмки, комплект передачи и регулярные расходы. Покажите похожий сценарий в выполненном проекте и объясните роль вашей команды.
Частые вопросы
Что выбрать: веб-студию или независимого разработчика?
Сравнивайте покрытие задач, ответственность и дальнейшую поддержку. Узкая задача может подходить одному специалисту. Проект с исследованиями, дизайном, содержанием и интеграциями требует согласованной работы нескольких компетенций. Уточните, кто фактически выполнит каждую часть и кто подменит основного исполнителя.
Нужно ли выбирать подрядчика с самой подробной сметой?
Количество строк не является самостоятельным критерием. Важнее, можно ли связать строки с результатами и способом проверки. Подробная смета с неопределёнными объёмами всё ещё оставляет существенные вопросы.
Можно ли сравнивать предложения до подготовки полного ТЗ?
Да, для предварительного выбора. Передайте одинаковое описание задачи, перечислите неизвестное и попросите указать границы оценки. Финальный состав и обязательства уточняются по мере проработки; предварительные диапазоны нужно сравнивать вместе с допущениями.
Обязательно ли переносить сайт на новую CMS?
Сначала проверьте, что мешает существующей системе: редактирование, нужный сценарий, интеграция или сопровождение. Попросите сравнить доработку и перенос с учётом данных, адресов и обучения команды. Само название CMS не объясняет, какая задача будет решена.
Обсудить разработку сайта с DDRW
Пришлите описание задачи, текущий сайт и основные сценарии. Разберём состав первой версии, вопросы к материалам и интеграциям, затем предложим следующий шаг для оценки.
Для публичного сайта начните с услуги «Сайты для бизнеса», для системы с ролями и связанными процессами — с веб-платформ и личных кабинетов. Связаться с DDRW.
