Как выбрать подрядчика веб-разработки: критерии, проверки и красные флаги

Чтобы выбрать подрядчика веб-разработки, достаточно проверить три вещи: понимает ли команда вашу бизнес-задачу, показывает ли она процесс работы и что останется у вас на руках при расставании. Всё остальное — портфолио, рейтинги, количество сотрудников — вторично. Красивый сайт студии не гарантирует, что ваш сервис запустится в срок.

Мы в Else Digital регулярно подхватываем проекты после других команд. Почти всегда провал был виден ещё на этапе переговоров. Просто заказчик не знал, на что смотреть. Ниже — критерии, по которым мы бы выбирали подрядчика сами, и список сигналов, после которых сделку лучше не начинать.

Типичная ошибка — начинать с поиска исполнителя. Человек гуглит «студии веб разработки», собирает десять контактов и рассылает одинаковый запрос: «нужен личный кабинет, сколько стоит». В ответ приходят десять несопоставимых цифр от 300 тысяч до 4 миллионов. Сравнить их невозможно.

Разброс возникает не потому, что кто-то жадный. Каждая команда достроила вашу задачу по-своему. Одна заложила авторизацию по СМС и интеграцию с 1С, другая — только фронтенд на готовом API. Пока задача не описана, вы сравниваете не подрядчиков, а их фантазии.

Перед рассылкой запроса ответьте себе на четыре вопроса. Какую операцию бизнеса сервис заменяет или ускоряет. Кто им будет пользоваться и сколько таких людей. С какими системами он обязан обмениваться данными. По какой метрике вы через полгода поймёте, что проект удался.

Это не техническое задание, а бизнес-рамка на полторы страницы. Её хватает, чтобы получить сопоставимые оценки. Если своими силами не выходит — нормальная практика заказать платную аналитику отдельным коротким этапом, у нас это 2–3 недели. Подробнее про структуру документа мы писали в материале о том, как составляются технические задания.

Аутсорс веб-разработки — не единственный вариант, и он не всегда выигрывает. Фрилансер стоит дешевле по ставке: 2500–4000 рублей в час против 3500–6000 у студии. На задаче в 200 часов разница около 400 тысяч. Соблазн понятный.

Дальше начинается арифметика рисков. Один человек не закрывает четыре роли сразу: аналитика, дизайн, бэкенд, тестирование. Он либо делает часть плохо, либо ищет подрядчиков сам, и вы платите его маржу вслепую. При болезни или новом более выгодном заказе проект встаёт целиком — резерва нет.

Свой штат оправдан, когда продукт живёт годами и меняется каждую неделю. Команда из тимлида, двух разработчиков, дизайнера и QA обходится в 1,2–1,8 млн рублей в месяц с налогами и техникой. Плюс два-три месяца на найм и период, когда люди только вникают. Для одного сервиса это дорого.

Студия закрывает промежуточный сценарий: нужен результат за 3–6 месяцев, без найма и с гарантией. Мы честно говорим клиентам: если у вас уже есть CTO и два сильных разработчика, берите нас точечно — на дизайн, интеграции или нагрузочное тестирование. Гибридная схема часто дешевле полного подряда на 20–30%.

Первый критерий — вопросы на первом созвоне. Хорошая команда спрашивает про деньги и процессы: откуда приходят клиенты, кто вносит данные сейчас, сколько заявок в день. Плохая — сразу про технологии и дедлайн. Если за час разговора вам не задали ни одного вопроса о бизнесе, оценка будет взята с потолка.

Второй — релевантное портфолио, а не объёмное. Двадцать лендингов не доказывают умение делать нагруженный B2B-портал. Просите проекты с похожей логикой: роли и права, расчёты, обмен с внешними системами. Один точный кейс весомее тридцати случайных. Например, наш проект Созвездие мебели показывает работу именно с каталогом и заказами.

Третий — доступ к людям, которые будут делать работу. На переговорах часто присутствует только продавец. Попросите 20 минут с тимлидом и задайте один вопрос: как он планирует разбить проект на этапы. Ответ «сделаем по спринтам» без деталей — плохой знак. Ответ с конкретикой по релизам — хороший.

Четвёртый — прозрачность процесса. Спросите, где вы будете видеть задачи, как часто получать демо, кто пишет статусы. У нас демо каждые две недели, доступ к таск-трекеру у клиента с первого дня. Пятый — отзывы от людей, а не с сайта студии. Просите два контакта прошлых заказчиков и звоните. Шестой — что происходит после релиза: есть ли поддержка, по какому SLA, за какие деньги.

Смета на одну строку «разработка веб-сервиса — 1 800 000 ₽» не говорит ни о чём. Нормальная оценка разбита по этапам и ролям, с часами. Вы должны видеть, сколько уходит на аналитику, дизайн, фронтенд, бэкенд, тестирование и внедрение. По нашей статистике аналитика и дизайн — это 20–30% бюджета, тестирование — ещё 15%.

Проверьте, что входит в «интеграцию». Это слово прячет самый большой риск. Интеграция с 1С может стоить 80 тысяч, если у клиента свежая типовая конфигурация и открытый обмен. И 600 тысяч, если конфигурация переписана и нужен отдельный слой обмена. Спросите прямо: что вы предполагаете и что будет, если предположение не подтвердится.

Сравните оценки между собой по объёму часов, а не по итоговой цифре. Если одна команда закладывает 120 часов на кабинет пользователя, а другая 400, кто-то не понял задачу. Задайте обоим один и тот же уточняющий вопрос — расхождение обычно объясняется за пять минут.

Отдельно уточните стоимость услуг разработки за пределами сметы: доработки после приёмки, срочные правки, работа в выходные. Мы фиксируем ставку на изменения в договоре сразу. Это снимает половину будущих споров о деньгах. Общую логику расчёта бюджета мы разбирали в статье Как создать веб-сервис: архитектура, этапы и цена.

Оценка за час без вопросов. Если подрядчик называет точную цену сразу после описания идеи в двух абзацах, он либо демпингует ради подписи, либо продаёт шаблон. Реальная оценка требует хотя бы одного созвона и пары дней на проработку.

Фиксированная цена на неопределённую задачу. Fix price работает, когда есть детальное ТЗ. Без него подрядчик закладывает риск в цену — обычно плюс 30–50%. Или принимает риск на себя и потом экономит на тестировании. Второе хуже: вы получите работающую демонстрацию и неработающий продукт.

Отказ показывать промежуточный результат. «Покажем, когда будет готово» — почти приговор. Первые видимые части должны появляться на 3–4 неделе. Если команда прячет процесс, чаще всего прятать есть что: людей перекинули на другой проект.

Сопротивление вопросу о правах на код. Здоровая реакция: «конечно, исключительные права переходят по акту». Нездоровая: «у нас своя платформа, мы вас поддержим». Второе означает пожизненную привязку. По статье 1296 ГК РФ права на программу, созданную по заказу, принадлежат заказчику, если в договоре не написано иное — а в шаблонных договорах студий как раз часто написано иное.

Ещё три сигнала помельче. Общение только через мессенджер без документов. Постоянная смена менеджера на этапе переговоров. Обещание сделать «за две недели» то, что другие оценивают в три месяца.

Договор проверяют по трём пунктам. Права на результат: код, дизайн-макеты, тексты. Формулировка должна включать передачу исключительных прав в полном объёме, а не лицензию на использование. Разница в деньгах видна, когда вы захотите доработать продукт другой командой.

Второй пункт — инфраструктура. Домен, хостинг, репозиторий, аккаунты в платёжных системах и сервисах рассылок должны быть оформлены на вас. Мы заводим клиента владельцем всех аккаунтов на первой неделе и добавляем себя как участников. Так расставание занимает один час, а не месяц переписки.

Третий — гарантия и приёмка. Что считается принятой работой, за какой срок вы обязаны дать замечания, сколько длится бесплатное исправление ошибок. Нормальная гарантия на код — 3–6 месяцев. Важно, чтобы в ней было чётко разделено: ошибка разработчика исправляется бесплатно, новое пожелание оплачивается отдельно.

Отдельно пропишите, что передаётся при завершении: исходники, инструкция по развёртыванию, схема базы, список внешних сервисов с их стоимостью. Мы отдаём это пакетом вместе с финальным актом. Когда такого пакета нет, следующая команда тратит 40–60 часов только на то, чтобы разобраться в чужом проекте.

Пример для замены на реальные данные проекта. К нам пришла компания из оптовой торговли: заказали личный кабинет для дилеров, заплатили 1,4 млн рублей, получили работающую демонстрацию и остановку за месяц до релиза. Предыдущий подрядчик перестал отвечать.

Мы взяли два дня на технический аудит. Код был, но лежал в репозитории студии, доступ у клиента отсутствовал. Дизайн-макеты — в аккаунте уволившегося дизайнера. Обмен с 1С работал только на тестовых данных: реальную номенклатуру в 12 000 позиций он не переваривал, запрос падал по таймауту на 40 секундах.

Разбор занял 9 рабочих дней. Оказалось, что 60% кода вполне пригодны — фронтенд написан аккуратно. Переписывать пришлось слой обмена и авторизацию. Мы вынесли синхронизацию в фоновую очередь, добавили кэш каталога, и время ответа упало с 40 секунд до 1,2 секунды. Запуск состоялся через 7 недель, бюджет доработки — около 600 тысяч рублей.

Главное в этой истории не техника. Клиент потерял четыре месяца и треть бюджета из-за двух пунктов договора, которых там не было: передачи прав и владения доступами. Проверка этих строчек заняла бы полчаса на этапе подписания.

Разумный способ — не подписывать сразу большой контракт. Начните с платного пилота: аналитика плюс прототип ключевого экрана, 2–4 недели, 150–300 тысяч рублей. За это время вы увидите, как команда задаёт вопросы, соблюдает сроки и реагирует на правки. Это дешевле, чем узнать то же самое на пятом месяце.

Дальше режьте проект на релизы по 4–6 недель, каждый со своей приёмкой и оплатой. Такая схема даёт точку выхода: вы можете остановиться после любого этапа с работающим куском продукта на руках. Мы работаем именно так на большинстве проектов, где разработка веб-сервисов идёт параллельно с реальной операционкой клиента.

Порядок действий на ближайшую неделю выглядит так:

— описать бизнес-задачу и метрику успеха на полторы страницы; разослать одинаковый запрос трём-пяти командам, не больше; на созвоне считать, сколько вопросов о бизнесе вам задали; попросить смету с разбивкой по этапам и часам; запросить два контакта прошлых заказчиков и позвонить им; проверить в договоре права на код, владение доступами и гарантию; договориться о пилоте вместо полного объёма.

Семь пунктов занимают около недели работы. Они закрывают примерно 80% рисков, с которыми мы сталкиваемся, когда подхватываем чужие проекты.

Сколько стоит разработка веб-сервиса у студии?

Простой сервис с одной ролью и без интеграций — от 600 тысяч рублей. Личный кабинет с обменом данными и платежами — 1,5–3 млн. Платформа с несколькими ролями, админкой и отчётностью — от 3,5 млн. Разброс определяют интеграции и количество бизнес-сценариев, а не количество экранов.

Как проверить студию, если я не разбираюсь в технологиях?

Смотрите на процесс, а не на стек. Попросите показать таск-трекер реального проекта, спросите про частоту демо и порядок приёмки. Позвоните двум прошлым клиентам и задайте один вопрос: что пошло не так и как команда себя повела. Ответ на него говорит больше, чем портфолио.

Что безопаснее — аутсорс или свои разработчики?

Для первого продукта — аутсорс: быстрее старт и нет затрат на найм. Когда сервис становится основой бизнеса и меняется еженедельно, выгоднее переводить его в штат. Частый рабочий вариант — студия делает первую версию и параллельно готовит документацию для будущей внутренней команды.

Что делать, если подрядчик сорвал сроки?

Сначала выясните причину: недооценка объёма, смена людей на проекте или ваши собственные правки. Зафиксируйте новый план письменно, с датами и ответственными. Если второй срок тоже сорван — запрашивайте исходники и доступы и проводите аудит у другой команды. Чем раньше, тем дешевле.

Правильно выбранный подрядчик не тот, кто дешевле или красивее презентует. Это тот, с кем вы понимаете, за что платите на каждом этапе, и от кого можете уйти без потерь. Проверка этих двух условий занимает неделю и экономит месяцы.

Если вам нужен взгляд со стороны на уже полученную смету — присылайте её нам. Мы бесплатно разбираем чужие оценки и говорим, где заложены риски, а где лишние часы. Обсудить задачу и получить расчёт можно на странице разработки веб-сервисов или через форму на сайте студии.