Большинство проблем с сайтом появляются не потому, что кто-то плохо умеет рисовать кнопки. Они начинаются там, где до старта не определены ответственность и результат. Кто пишет тексты? Кто настраивает формы? Где будут исходники? Что происходит, если через месяц нужно изменить услугу? Эти вопросы лучше задать до оплаты.
Попросите объяснить процесс простыми словами
Хорошая команда может рассказать, что будет происходить от первого разговора до запуска: исследование, структура, дизайн, разработка, контент, тестирование, перенос и проверка production. Если ответ сводится к «сделаем современно и красиво», непонятно, кто отвечает за бизнес-задачу.
Уточните, кому принадлежат домен, файлы и доступы
Домен и хостинг должны контролироваться бизнесом. Исходные файлы, доступы и инструкции не должны превращаться в заложников подрядчика. Нормальная поддержка строится на ценности работы, а не на невозможности уйти.
SEO и скорость должны появляться не после запуска
Canonical, sitemap, заголовки, мобильная версия, оптимизация изображений и базовая структура — это часть разработки. Если команда планирует «когда-нибудь потом подключить SEO», часть архитектуры придётся переделывать. То же со скоростью: тяжёлый сайт сложно лечить после того, как в него уже встроили десяток лишних библиотек.
Спросите, как будут исправляться ошибки
Ошибки случаются в любом проекте. Важнее реакция: есть ли тестовая среда, проверяется ли diff, можно ли откатить рискованное изменение, как быстро команда признаёт проблему и исправляет её у источника, а не закрывает новым костылём.
- понятный состав работ и границы проекта
- контроль бизнеса над доменом и хостингом
- доступ к исходникам и нормальная структура файлов
- SEO, аналитика и безопасность в базовой сборке
- процесс поддержки и отката после запуска
Портфолио всё равно важно — но смотрите глубже
Откройте проекты на телефоне, попробуйте формы, посмотрите реальные внутренние страницы, а не только первый экран. Если возможно, узнайте, как сайт поддерживается спустя год. Именно это лучше показывает качество архитектуры.
Осторожнее с обещанием «сделаем всё на конструкторе за три дня»
Конструктор сам по себе не плох и в некоторых проектах действительно экономит время. Риск начинается, когда инструмент выбирают до задачи. Если сайту нужны нестандартные интеграции, сложная SEO-структура или особая логика, ограничения платформы позже оплачивает заказчик.
Поэтому спрашивайте не «на чём вы делаете сайты», а «почему этот стек подходит моему проекту и что будет, если через год появится новая задача». Сильный ответ обычно содержит компромиссы, а не заявление, что один инструмент подходит всем.
На что смотреть кроме красивого портфолио
Портфолио показывает вкус, но не отвечает на главный вопрос: как команда ведёт проект. Для бизнеса намного важнее понять, как подрядчик выясняет задачи, как проектирует структуру, кто отвечает за контент, тестирование и запуск, что происходит после публикации и как вносятся правки. Хороший разработчик говорит не только о «дизайне», а о результате и процессе.
- умеет ли команда задавать вопросы про цели, аудиторию и продажи
- есть ли понятные этапы: структура, дизайн, разработка, тестирование, запуск
- объясняет ли подрядчик, что именно входит в смету
- как устроена коммуникация и кто ведёт проект
- есть ли поддержка после запуска и понятный порядок правок
Какие тревожные признаки лучше заметить заранее
Стоит насторожиться, если подрядчик обещает всё и сразу без погружения в задачу, говорит только о визуале, не задаёт вопросов о бизнесе и избегает разговора о поддержке. Ещё один плохой сигнал — когда в предложении нет состава работ, сроков и понятных результатов по этапам. Для бизнеса безопаснее работать с теми, кто прозрачно объясняет не только «что сделает», но и «как будет к этому идти».
Проверяйте, как подрядчик мыслит на примере вашей задачи
На первой встрече хороший сигнал — когда команда не спешит продавать конкретный стек или пакет, а задаёт вопросы: откуда сейчас приходят клиенты, какие услуги приоритетны, кто будет обновлять контент, какие интеграции обязательны, есть ли SEO-задачи и как измеряется результат. По качеству вопросов часто лучше видно зрелость подрядчика, чем по эффектной презентации.
Узнайте, где будут жить контент и бизнес-логика
Если на сайте регулярно меняются цены, услуги, статьи или проекты, стоит понимать, сможет ли редактор менять их без разработчика. Если есть сложные расчёты, кабинеты или интеграции — где хранится бизнес-логика и как она тестируется. Это не означает, что каждому сайту нужна CMS или сложный framework. Важно, чтобы архитектура соответствовала реальной частоте изменений, а не привычке исполнителя.
- попросите назвать источник истины для цен, контактов и других повторяющихся данных
- уточните, как выполняется backup и rollback перед рискованными изменениями
- спросите, какие проверки проходят формы и мобильная версия перед релизом
- убедитесь, что секреты и доступы не будут храниться в публичном репозитории
- проверьте, сможете ли вы забрать проект, домен, код и данные без зависимости от подрядчика
Нормальная разработка заканчивается не макетом, а работающим production
В стоимость и процесс должны входить перенос, проверка HTTPS, форм, аналитики, индексируемости и критичных страниц. Если исполнитель считает проект завершённым после передачи дизайна или архива, значительная часть рисков остаётся у заказчика. Сайт становится бизнес-инструментом только после корректного запуска и проверки в реальной среде.
Как сравнивать два похожих предложения
Сравнивайте не цену строки «сайт», а конечный состав: структура, количество уникальных шаблонов, контент, адаптив, SEO-база, аналитика, интеграции, тестирование, запуск, гарантийный период и поддержка. Более дорогая смета может оказаться дешевле в эксплуатации, если в ней сразу решены вещи, за которые в другом предложении придётся доплачивать после запуска.
Попросите показать не только результат, но и сопровождение после релиза
Полезно узнать, что происходило с проектом через несколько месяцев после запуска. Хороший сайт обычно развивается: появляются статьи, новые услуги, SEO-страницы, интеграции и корректировки по аналитике. Если подрядчик умеет только запустить первую версию, но любая следующая правка становится проблемой, стоимость владения растёт. Сильная команда думает о поддерживаемости ещё во время разработки.
- как быстро меняется типовая цена или услуга
- как добавляется новая статья или кейс
- кто владеет репозиторием и документацией
- может ли другой разработчик продолжить проект без полной реконструкции
Это особенно важно для бизнеса, который планирует SEO и постоянное развитие. Сайт не должен быть одноразовым рекламным макетом. Он должен оставаться понятной системой, где контент меняется в предсказуемом месте, общие компоненты не дублируются, а релиз не требует каждый раз рисковать всей production-средой.
