Хороший подрядчик не обязательно самый дорогой и не обязательно самый известный. Важно, чтобы команда понимала задачу, могла показать похожий опыт, прозрачно ограничивала scope и передавала результат, которым бизнес сможет владеть и управлять.
Почему стоимость — не единственный критерий
Две сметы нельзя сравнивать по последней строке, пока не сопоставлен состав. В одном предложении могут быть аналитика, дизайн, CMS, интеграции и поддержка, в другом — только сборка страниц из материалов заказчика.
Слишком низкая цена часто означает неопределенность: важные работы не исчезают, а появляются позже как доплаты или остаются невыполненными. Слишком высокая тоже ничего не гарантирует без понятного процесса.
Фрилансер, небольшая студия или агентство
Фрилансер удобен для узкой задачи и прямой коммуникации. Риск — зависимость от одного человека и ограниченный набор компетенций.
Небольшая студия обычно сочетает личное участие ключевых специалистов и возможность закрыть дизайн, backend и QA. Нужно проверить, какие роли штатные и кто отвечает за результат.
Крупное агентство полезно для большого объема и сложной координации, но включает больше процессов и менеджмента. Выбор должен соответствовать масштабу, а не престижу логотипа.
Смотрите реальные кейсы
Кейс должен объяснять задачу, ограничения, решение и результат. Красивый скриншот без контекста мало говорит о качестве разработки. Попросите открыть живой продукт и показать, какую часть делал подрядчик.
На страницах портфолио и кейсов KBK TechLab мы разделяем визуальные работы и описания внедрений.
Проверяйте авторство проекта
Уточните роль команды: весь продукт, только дизайн, отдельный модуль или поддержка. Нормальный подрядчик спокойно описывает границы своего участия и не присваивает чужую работу.
Просите показать работающие продукты
Если NDA позволяет, проверьте мобильную версию, скорость, формы и реальные состояния. Для закрытых систем попросите демонстрацию без клиентских данных или технический рассказ о похожей задаче.
Как собирают требования
Тревожный сигнал — цена на сложный проект после одного сообщения. Сначала команда должна узнать цель, пользователей, контент, интеграции, ограничения и приоритеты. Для предварительного диапазона достаточно брифа, для фиксированной сметы нужна декомпозиция.
Фиксированный scope
В scope перечисляют страницы, функции, интеграции, результаты этапов и то, что не входит. Иначе фраза «сделать личный кабинет» будет означать разное для заказчика и разработчика.
Изменения неизбежны. Важно заранее договориться, как оцениваются новые задачи и что происходит со сроком. Подробнее о составе проекта — в статье про сайт под ключ.
Договор
Договор фиксирует стороны, предмет, этапы, стоимость, приемку, права на результат, конфиденциальность и гарантию. Приложение со scope полезнее десятка общих обещаний в переписке.
Этапность оплаты
Для большого проекта разумны платежи по этапам: старт, прототип, дизайн, разработка, запуск. Это дает обеим сторонам контроль. Схема зависит от проекта, но 100% предоплата без результатов и критериев приемки увеличивает риск.
Исходный код и Git
Уточните, кому принадлежит код и когда заказчик получает доступ. Репозиторий хранит историю изменений, позволяет проводить review и снижает зависимость от конкретного компьютера разработчика.
Git не гарантирует качество, но отсутствие репозитория у командного проекта — серьезный вопрос. Хорошая практика — организация заказчика или прозрачная передача репозитория после согласованного этапа.
Домен, сервер и аккаунты
Домен желательно регистрировать на заказчика. Аналогично с облаком, аналитикой, платежным кабинетом и почтой. Подрядчику выдают доступ, а не оформляют критичную инфраструктуру на его личный аккаунт.
Проверьте, кто оплачивает сервисы, где хранятся секреты и как будет отозван доступ после завершения работ.
Как организована разработка
Спросите о коротких демонстрациях, канале коммуникации и частоте статусов. Не нужен сложный ритуал, но заказчик должен регулярно видеть работающий результат, а не ждать несколько месяцев финального показа.
Полезно узнать, кто принимает технические решения, кто проверяет код и как фиксируются изменения требований.
Тестирование
Уточните, какие браузеры и устройства проверяют, кто тестирует формы и интеграции, есть ли staging. Для магазина отдельно обсудите тестовые платежи, возвраты и повторные callback. Для кабинета — роли и доступ к данным.
Что происходит после релиза
Запуск не заканчивается загрузкой файлов. Нужны smoke-тест, мониторинг, резервные копии и период гарантии. Для развития согласуют SLA или новый backlog. Узнайте время реакции на критическую ошибку до того, как она случится.
Красные флаги
- Обещание сложного сайта за пару дней без уточняющих вопросов.
- Отсутствие описанного scope или технического задания.
- Отсутствие репозитория у командного проекта.
- Полная предоплата без этапов и критериев приемки.
- Невозможность простыми словами объяснить архитектуру.
- Нет плана тестирования и поддержки.
- Домен, хостинг и платежные аккаунты оформляются на подрядчика.
- Портфолио состоит из макетов, которые нельзя открыть.
- Команда обещает гарантированные позиции в поиске без анализа ниши.
Один признак не всегда означает проблему. Но несколько вместе — повод остановиться и уточнить условия письменно.
Вопросы подрядчику перед стартом
- Как вы поняли бизнес-цель проекта?
- Что входит и не входит в оценку?
- Какие похожие задачи вы решали?
- Кто будет работать над проектом?
- Как фиксируются изменения scope?
- Где будет храниться код и когда мы получим доступ?
- На кого оформляются домен, сервер и внешние аккаунты?
- Как проходит тестирование и приемка?
- Какие гарантии действуют после запуска?
- Как оценивается дальнейшая поддержка?
Как сравнить предложения
Соберите единую таблицу: результат этапа, технологии, контент, интеграции, срок, стоимость, гарантия и владение активами. Это быстро показывает, почему сметы отличаются.
Ориентиры стоимости есть в статье о ценах на разработку сайта. Обсудить проект с KBK TechLab можно на странице разработки сайтов или в контактах.
FAQ
Нужно ли требовать фиксированную цену?
Для понятного scope — да, хотя бы по этапам. Для исследования или продукта с высокой неопределенностью честнее фиксировать бюджет этапа и ожидаемый результат.
Как проверить техническую компетентность без своего разработчика?
Попросите объяснить архитектуру простыми словами, показать репозиторий или документацию аналогичного проекта и при крупном бюджете заказать независимый review.
Кому должны принадлежать дизайн-макеты?
Права и порядок передачи фиксируются в договоре. Заказчику нужны исходники или доступ к рабочему пространству, если это входит в результат.
Нормально ли использовать шаблон?
Да, если это осознанный выбор для стандартной задачи и ограничения известны заранее. Плохо выдавать шаблонную сборку за индивидуальную разработку.
Когда можно начинать без полного ТЗ?
С discovery или прототипа. Начинать всю разработку без зафиксированных целей и границ рискованно.