Как понять, что вам продают “чужой стек” и потом замучают доплатами
Есть две модели продажи разработки. Первая: вам продают результат — работающий процесс и систему, которую можно поддерживать. Вторая: вам продают “набор технологий” и обещание, что “всё решим”. Вторая модель опасна, если стек для команды не родной или держится на одном человеке.
Признаки, что стек “чужой” (и потом будет больно)
1) Они говорят про технологии, но плохо говорят про ваш бизнес‑процесс.
Если на встрече вам час рассказывают “что мы используем”, но не могут внятно повторить, как у вас проходят заявки/оплаты/отгрузки — они продают не решение.
2) На вопросы про поддержку отвечают туманно.
Нормальные ответы: “у нас 3 человека, которые умеют это поддерживать”, “есть регламент обновлений”, “есть база знаний”. Плохие ответы: “да там всё просто”, “главное запустить”.
3) “Это сложно” появляется слишком рано.
Когда любая ваша просьба вызывает реакцию “в нашем стеке это тяжело” — часто это не про сложность, а про отсутствие опыта именно в этом наборе решений.
4) Вас сразу подсаживают на “платные модули/плагины” без альтернатив.
Плагины — не зло. Зло — когда проект критически зависит от набора платных коробок, а замена невозможна или “будет в 10 раз дороже”.
5) Нет понятного ответа, что будет, если ключевой разработчик уйдет.
Если проект держится на одном “сеньоре”, вы покупаете риск, а не продукт.
Вопросы, которые быстро вскрывают ситуацию
Спросите прямо и простыми словами — как собственник:
- Кто конкретно будет делать проект и кто сможет подхватить?
Вам не нужны фамилии в рекламе. Вам нужна гарантия, что это не “один человек всё знает”. - Где будет храниться код и кому он принадлежит?
Ответ “у нас на аккаунте, так проще” — тревожный. Код и доступы должны быть у вас (или минимум совместно). - Как вы обновляете технологии и кто за это платит?
Если ответ “мы не обновляем, чтобы не ломалось” — это бомба замедленного действия. Если ответ “обновим, когда понадобится” — ждите доплат и сюрпризов. - Что будет стоить дороже всего в изменениях?
Попросите назвать 3 зоны риска: интеграции, роли, отчеты, миграции данных и т.д. Вменяемый подрядчик честно говорит, где обычно “вылезает” стоимость. - Дайте пример похожего проекта и расскажите, как его поддерживали после запуска.
Не “мы делали”, а “как жили 6–12 месяцев”: сколько обращений, что ломалось, как фиксили.
Как защититься, даже если вы не технарь
- Требуйте прозрачности: где код, где задачи, кто отвечает, как принимается работа.
- Фиксируйте правила изменений: новая хотелка = оценка + влияние на срок/бюджет + решение “делаем/не делаем”.
- Закладывайте переносимость: документация, доступы, инструкции — не “потом”, а условие приемки этапа.
- Смотрите на поведение: уверенная команда спокойно отвечает на вопросы и не прячет “кухню”.
Главная мысль: вам не нужен “самый модный стек”. Вам нужна система, которая не превращает каждое изменение в отдельный финансовый подвиг.