Запрос «нужен новый сайт» часто маскирует другую задачу. На первом созвоне выясняется, что сайт уже есть, а бизнесу нужны дилерский кабинет, остатки из ERP, заявки в CRM, роли для менеджеров, аналитика по воронке. В такой ситуации искать стоит не «программиста», а того, кто возьмет на себя часть процесса, влияющего на выручку.
Я вижу эту ошибку много лет: компанию выбирают по вывеске, а не по зоне ответственности. Потом теряют 3-6 месяцев на пересборку команды, требований и бюджета.
Сначала определите, что именно у вас ломается
Фраза «нужен разработчик» для бизнеса слишком общая. Если задача сводится к лендингу, правкам на WordPress или небольшому модулю, сильный фрилансер или маленькая веб-студия часто справляются нормально. Когда появляются роли пользователей, CRM, ERP, аналитика, регулярные релизы и поддержка, один человек почти всегда упирается в потолок.
У нас был B2B-дистрибьютор, который хотел нанять одного backend-разработчика для кабинета клиентов. Через 4 месяца стало понятно, что без UX, интеграции с 1С, событий в GA4 и поддержки после запуска проект начнет буксовать. Мы пересобрали работу в компактную команду: Node.js 20 + NestJS, Next.js 15, PostgreSQL 16, QA на регресс. MVP выпустили за 14 недель вместо ожидаемых 8-9 месяцев.
Обычно разговор здесь выглядит просто:
- Нам нужен программист.
- Для чего именно?
- Чтобы сделать кабинет.
- Кабинет как страницу после входа или как часть продаж, логистики и CRM?
Разница между этими двумя вариантами кабинета - это разница в риске, составе команды и бюджете.
Смотрите не на название подрядчика, а на его ответственность
Для владельца бизнеса полезнее спрашивать не «что это за компания», а «за какой результат она готова отвечать». Веб-студия обычно сильна там, где нужен сайт, каталог, типовой e-commerce. Digital-агентство полезно, когда задача в трафике, контенте, аналитике и воронке. Dev-команда нужна там, где есть кастомная логика, API, роли, автоматизация и поддержка после релиза.
| Задача | Кого брать | Что проверить |
|---|---|---|
| Лендинг | фрилансер или небольшая веб-студия | сроки, CMS, базовое SEO |
| Корпоративный сайт | веб-студия | контентная модель, редакторка |
| Личный кабинет, B2B-сервис | dev-студия или IT-команда | API, роли, QA, поддержка |
| Лиды и воронка | digital-агентство + разработка | аналитика, CRM, стоимость лида |
У розничной компании, которая пришла за редизайном, проблема оказалась не в интерфейсе. На разборе в Miro мы увидели, что 60% потерь идет из ручной обработки заказов и неверных остатков. Вместо нового сайта сделали связку витрины, Bitrix24 и синхронизации с 1С. Отмененные заказы снизились на 27% за 7 недель.
Хороший подрядчик продает ясность: что именно заработает после запуска и кто за это отвечает.
Быстрая оценка сложного проекта обычно ничего не стоит
Если стоимость называют через 10 минут после брифа, я отношусь к ней как к предположению. Для нормальной оценки нужно понять роли пользователей, ограничения старой системы, список интеграций, критичные сценарии и то, кто принимает результат внутри компании.
Мы обычно начинаем с короткого discovery на 1-3 недели. На этой фазе разбираем сценарии, проверяем интеграции и собираем MVP без лишнего. В проектах B2B и B2C после такой проработки меняется 20-40% требований. Это дешевле, чем переписывать уже запущенный кусок системы.
Один клиент принес три оценки кабинета партнеров: 1,2 млн ₽, 2,8 млн ₽ и 6,4 млн ₽. Все выглядело правдоподобно, но считали разное: только фронтенд, фронтенд с бэкендом и систему целиком - с API, логированием, ролями и SLA. После 2 недель проработки объем работ сократился на 22%.
Оценка без discovery -> высокий риск пересборки
Discovery -> сценарии -> backlog MVP -> диапазон бюджета -> roadmap
Если задача типовая, fixed price работает. Если в проекте есть 1С, ERP, роли, кабинет и API, фикс на старте часто заканчивается спором о том, что «это не входило».
Портфолио показывает вкус, но не показывает, как команда поведет проект
Красивые кейсы полезны, но покупать стоит способ работы. Зрелый проект живет не до первой презентации, а следующие 12-18 месяцев: с багами, релизами, доступами, правками и поддержкой legacy.
Что я бы запросил еще на пресейле:
- где ведут задачи - Jira, YouTrack, Trello
- где хранится код - GitHub или GitLab
- есть ли staging, Docker, CI/CD
- как описывают API - Swagger, OpenAPI, Postman
- кто отвечает за поддержку после релиза
Можно ли выбрать подрядчика без техлида на созвоне?
Можно, если задача простая. Для кабинета, автоматизации или сервиса я бы хотел увидеть человека, который потом реально поведет проект. Иначе вы покупаете обещание, а не способ работы.
В одном тендере выиграла команда без самого яркого портфолио. До старта они показали карту зависимостей между CRM, ERP, каталогом, платежкой и аналитикой. Это позволило убрать 11 рискованных интеграций еще до запуска сезона.
Иногда лучший выбор - тот, кто урезает первый релиз
Мы тоже ошибались в таких решениях. У стартапа в прошлом году сразу утвердили большую сборку: много ролей, спорные интеграции, длинный список сценариев. За 5 месяцев проект разросся, пилотов не было, приоритеты плавали. Его заморозили. Проблема была не в людях - объем взяли раньше проверки спроса.
На другом B2B SaaS-проекте мы на discovery сократили объем с 14 сценариев до 3. Стартовый бюджет уменьшился почти в 2,5 раза, а к пилотным клиентам вышли на 4 месяца раньше. Метрики потом показали, что именно эти три сценария давали почти весь ежедневный трафик внутри продукта.
Перед тендером я бы задал себе один вопрос: вам нужен сайт, поток лидов или цифровой процесс, без которого продажи тормозят, - и кого вы на самом деле нанимаете под эту задачу?
