Как выбрать подрядчика на разработку ПО и не потерять деньги

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

Разберём, на что реально смотреть при выборе подрядчика, какие вопросы задавать на первом созвоне, какие красные флаги означают «беги» и что должно быть в договоре. Это применимо и к разработке приложения, и к CRM/ERP, и к сайту — принципы одни.

Почему это решение дороже, чем кажется

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

В нашей практике в NorthCode к нам не раз приходили после неудачной работы с другими разработчиками. Например, владелец проекта «КиноСтарт» пришёл после провального опыта: мы честно показали ошибки в существующем продукте, и проект решили делать с нуля. За месяц реализовали всё — от дизайна до запуска на сервере. Вывод, который повторяется из проекта в проект: «переделать за кем-то» почти всегда дороже и дольше, чем сделать правильно сразу.

На что смотреть в первую очередь

1. Релевантные кейсы, а не просто красивое портфолио

Важно не количество работ, а наличие похожих задач. Делал ли подрядчик интеграции с 1С, если они вам нужны? Запускал ли приложения с оплатой и лояльностью? Работал ли с вашей отраслью или близкой? Просите показать кейсы, близкие к вашей задаче, и спрашивайте про результат, а не только «как красиво получилось»: что было до, что стало, какие были сложности и как их решили.

Реальный кейс — это история с проблемой и решением. «Сделали красивое приложение» — это не кейс, это скриншот.

2. Процесс, а не обещания

Хороший подрядчик начинает с аналитики, а не с «давайте сразу делать». На первом созвоне спросите:

• Как устроен процесс: этапы, что на каждом, какие результаты на выходе.

• Будет ли ТЗ и проектирование до начала разработки.

• Как часто демо и как именно вы будете контролировать ход.

• Что происходит, если в процессе меняются требования.

• Кто конкретно будет работать над проектом и как с ними связь.

Если в ответ только «всё сделаем, не переживайте, мы профессионалы» — это плохой знак. Размытость в процессе означает размытость в результате.

3. Прозрачная цена и нормальный договор

В договоре должны быть зафиксированы объём, этапы, сроки, стоимость и условия приёмки. Размытое «разработка системы — N рублей» без детализации — риск: непонятно, за что платите и что считается выполненным. Нормально, когда цена разбита по этапам и понятно, что входит в каждый.

4. Что происходит после запуска

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

5. Кому принадлежит код

Критичный и часто забываемый пункт. Вы должны владеть кодом и иметь к нему доступ (репозиторий, доступы к серверам). Иначе вы заложник: захотите сменить подрядчика или нанять своих — а кода у вас нет. Это прописывается в договоре.

Красные флаги

Признаки, при которых стоит насторожиться или развернуться:

• Цена сильно ниже рынка. «ERP за 300 тысяч», «приложение за неделю», «CRM под ключ за 100к» — либо не понимают объём, либо сделают так, что придётся переделывать. Дёшево в разработке почти всегда означает дорого в переделке.

• Нет аналитики и ТЗ. Готовы «сразу кодить» без разбора процессов — переделки практически гарантированы.

• Нет договора или он размытый. Всё «на доверии и на словах» — нет защиты ни у кого, и спросить будет не с кого.

• Не отдают код и доступы. Если уклоняются от вопроса о правах на код — это серьёзный риск зависимости.

• Обещают всё и сразу. Реалистичный исполнитель честно говорит про риски, ограничения и сроки, а не только «да-да, легко, без проблем».

• Не спрашивают про ваш бизнес. Если подрядчик говорит только про дизайн и технологии, но не задаёт вопросов про ваши процессы и цели — он сделает «красиво», но не «работающе».

• Не отвечают про поддержку. Значит, не планируют быть рядом после запуска.

Правильные вопросы подрядчику

Короткий список, который на первом созвоне отсеивает большую часть рисков:

1. Покажите кейс, похожий на нашу задачу. Что было до и что стало?

2. Как выглядит ваш процесс и какие этапы до старта разработки?

3. Будет ли ТЗ и кто его делает?

4. Кому принадлежит код и где он хранится?

5. Что с гарантией и поддержкой после запуска?

6. Как меняются договорённости и цена, если в процессе меняются требования?

7. Кто конкретно будет работать над проектом?

По тому, насколько уверенно и конкретно отвечают на эти вопросы, уже многое понятно.

Чек-лист перед подписанием договора

• Есть релевантные кейсы, и можно проверить результат (контакты клиентов или работающие продукты).

• Зафиксированы объём, этапы, сроки, цена и условия приёмки.

• Прописаны права на код и передача доступов.

• Понятен процесс контроля (демо, отчётность, точки приёмки).

• Есть условия гарантии и поддержки после запуска.

• Подрядчик задавал вопросы про ваш бизнес и процессы, а не только «что нарисовать».

• Цена и состав работ выглядят адекватно рынку (не подозрительно дёшево).

Разбор: как выглядит правильный подход

Наш подход в NorthCode мы формулируем как «архитектура, а не макеты»: мы разбираемся в бизнес-целях и процессах до того, как писать код, фиксируем этапы и результаты, отдаём код заказчику и остаёмся на связи после запуска (гарантия и поддержка). Это и есть страховка от сценария «начать заново»: проект строится под реальные процессы, а не под красивую картинку, и у клиента всегда есть и код, и понимание, что происходит.

Это не «реклама себя», а описание того, как в принципе должен выглядеть нормальный процесс. Если у выбранного вами подрядчика он другой — это повод задуматься.

Частые вопросы

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

Как проверить кейсы? Просите контакты клиентов или хотя бы публичные ссылки на работающие продукты. Реальный подрядчик покажет, тот, у кого кейсы «нарисованы», будет уходить от ответа.

Что если бюджет ограничен? Это нормально — начните с MVP под самый важный процесс. Хороший подрядчик поможет урезать объём с умом, а не просто сделает дёшево и плохо.

Стоит ли брать самого дешёвого? Почти никогда. Низкая цена обычно означает урезанный объём (нет аналитики, интеграций, поддержки) или неопытность. Переделка выйдет дороже изначальной экономии.

Как понять, что подрядчик меня «ведёт», а не понимает задачу? Если он не задаёт вопросов про ваш бизнес, не предлагает аналитику и соглашается на всё подряд без обсуждения рисков — он, скорее всего, просто хочет получить заказ, а не сделать работающий продукт.

Что важнее — цена или процесс? Процесс. Прозрачный процесс с аналитикой, этапами и контролем почти всегда приводит к работающему результату. Низкая цена без процесса — к переделке.

Что в итоге

Подрядчика выбирают не по красивому сайту и низкой цене, а по способности довести проект до работающего результата. Смотрите на релевантные кейсы (с результатом, а не картинками), на процесс (аналитика, ТЗ, этапы, контроль), на договор (объём, сроки, права на код) и на то, что будет после запуска (гарантия и поддержка). Красные флаги — подозрительно низкая цена, отсутствие аналитики, нежелание отдавать код и обещания «всё и сразу». И помните: переделать за кем-то почти всегда дороже, чем сделать правильно сразу.

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