Пять признаков, что перед вами нормальная команда
- 01Задают неудобные вопросы до сметы. Хороший подрядчик сначала выясняет, зачем вам продукт и что считается успехом, и только потом называет цифру.
- 02Готовы отговорить. Если задача решается готовым сервисом за $50 в месяц, вам скажут об этом, а не продадут разработку за $30 000.
- 03Смета разбита по этапам. Видно, что входит в каждый, и на чём можно сэкономить осознанно.
- 04Показывают промежуточный результат. Демо каждые две недели — это норма, а не привилегия.
- 05Спокойно говорят про риски. «Всё будет идеально» — это красный флаг, а не уверенность.
Красные флаги
- Цена названа сразу, без вопросов. Значит, вам продают шаблон, а не решение вашей задачи.
- Слишком дёшево. Работа команды стоит денег; сумма вдвое ниже рынка означает либо студентов, либо то, что остальное появится в допсоглашениях.
- Отказ показать промежуточные результаты «пока не готово». За этим обычно скрывается, что работа не начиналась.
- Нет договора или в нём нет ни сроков, ни состава работ, ни принадлежности кода.
- Единственный контакт — менеджер, который не может ответить ни на один технический вопрос и всё «уточнит у команды».
Четыре вопроса, которые стоит задать
Задайте их всем, кого рассматриваете. Ответы разведут кандидатов быстрее любого портфолио.
- «Кому принадлежит код и доступы после оплаты?» Правильный ответ — вам, полностью, вместе с репозиторием и сервером.
- «Что происходит, если проект выйдет за срок?» Нормальный ответ описывает механику, а не обещает, что этого не случится.
- «Кто конкретно будет работать и сколько человек?» Если состав команды — тайна, скорее всего, проект отдадут на субподряд.
- «Что входит в поддержку после запуска и сколько она стоит?» Молчание об этом на старте означает счёт потом.
Как устроена честная смета
В нормальной смете видно три вещи: что именно входит в базу, что стоит отдельно и от чего зависит итоговая цифра. Если смета — одна строка «разработка сайта, $18 000», вы не сможете ни сравнить предложения, ни понять, за что платите.
Отдельно проверьте, совпадают ли цифры в разных местах: в коммерческом предложении, на сайте подрядчика и в договоре. Расхождение — не мелочь, а показатель того, как с вами будут работать дальше. Наши вилки опубликованы открыто — в рубрике «Цены и сроки» и в калькуляторе на главной.
Что должно быть в договоре
- Состав работ и что считается сдачей этапа — иначе «готово» у каждого своё.
- Права на исходный код, дизайн и данные переходят к вам после оплаты.
- Порядок изменений: как оформляется новая хотелка и как она влияет на срок и цену.
- Гарантия на исправление ошибок и время реакции после запуска.
- NDA, если вы показываете внутренние процессы или данные клиентов.
Частые вопросы
Нужно ли техническое задание до начала?
Подробное ТЗ на сто страниц до старта чаще вредит: пока его пишут, задача успевает измениться. Достаточно понимать цель, сценарии пользователей и ограничения — остальное уточняется по ходу, если подрядчик показывает результат каждые две недели. Но фиксировать состав работ в договоре нужно обязательно.
Что делать, если подрядчик исчез посреди проекта?
Ситуация неприятная, но решаемая, если доступы изначально оформлены на вас. Мы регулярно подхватываем такие проекты: начинаем с аудита кода и инфраструктуры и честно говорим, что выгоднее — продолжать или переписывать.
Дороже — значит лучше?
Нет. Цена отражает уровень команды и объём работ, но не гарантирует результат. Смотрите на то, как считают смету, задают ли вопросы и готовы ли показывать промежуточные результаты — это предсказывает исход лучше, чем сумма.
Как проверить портфолио?
Откройте показанные проекты и посмотрите, работают ли они сейчас, быстро ли грузятся, живой ли контент. Спросите, что именно делала команда: часто в портфолио попадают проекты, где подрядчик сделал только один экран.
А если у подрядчика нет публичного портфолио из-за NDA?
Это нормальная ситуация для корпоративных и финтех-проектов: почти все такие договоры закрыты NDA, а часть работ идёт по модели white-label, где продукт выходит под брендом заказчика. Проверять в этом случае нужно не логотипы, а конкретику: попросите показать договор с закрытыми названиями, сами системы в работе на созвоне под встречный NDA и контакты для рекомендаций. Выдуманный опыт такую проверку не проходит.
Материалы пишут инженеры, работающие на проектах, — но без подписи именем. Причина та же, по которой на сайте нет логотипов клиентов: почти все проекты идут под NDA или white-label, и авторство статьи о платёжном ядре указывает на заказчика не хуже логотипа. Взамен мы отвечаем за текст правилами, а не именами — кроме материалов о собственном открытом коде: те подписаны автором.
Как мы пишем и что проверяем