Какой стек выбрать, чтобы не попасть
в зависимость
от подрядчика

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

Тут начинается то, что называют vendor lock-in — ситуация, когда компания становится зависимой от одного подрядчика, потому что перейти к другому почти невозможно. Новый разработчик просто не сможет быстро разобраться в проекте. Не потому что он слабый, а потому что всё сделано слишком "по-своему", нестандартно. И тогда появляется настоящая зависимость: техническая и финансовая. Каждый новый доработанный модуль стоит как разработка с нуля, каждый перенос — как полноценный проект.

Но ведь можно иначе. Можно изначально выбирать те инструменты, которые распространены, хорошо задокументированы и поддерживаются сообществом. Там, где вы завтра найдёте десятки специалистов, если вдруг что-то случится. Там, где на Stack Overflow уже есть ответы на типовые вопросы. И там, где вы понимаете, что не одиноки

Это не значит, что надо отказываться от новых технологий. Речь о балансе. О том, чтобы не гнаться за уникальностью в ущерб устойчивости. Если подрядчик предлагает экзотику, стоит задать вопрос: а зачем? Есть ли на это объективные причины, или это просто комфортная зона для команды, которая хочет "закрыть" вас на себя?

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

Так что выбор стека — это не просто выбор технологии. Это выбор зависимости. Или независимости.