Или почему shiny tech stack ≠ рабочий продукт.

В современном IT есть незаметный, но опасный тренд: влюблённость в технологии, а не в результат.

Каждую неделю выходят новые «киллеры» фреймворков, базы данных, фреймворки на фреймворки, UI-библиотеки, подходы к state management, архитектурные паттерны и всё прочее.

И команда — чаще всего молодая и горящая — тащит их в прод:

Здесь проще. С этим быстрее. У нас будет красиво, как в статье на Medium

На демо — действительно красиво. А потом приходит прод.

Когда инструмент работает не на тебя, а против

В одном проекте (B2B-платформа) было принято решение перейти на модную NoSQL БД. Синтетические бенчмарки сулили бешеную производительность, а статья “как мы ускорили всё в 20 раз” казалась аргументом для молодых разработчиков.

Спустя 3 месяца:

• база не тянула растущий трафик,

• появилось странное поведение при индексации,

• шардирование пришлось пилить вручную,

• бэкапы оказались полуручными,

• а любые вопросы в гугле приводили на GitHub с unanswered issue

Всё закончилось тем, что часть системы пришлось переписать — на проверенный, пусть и скучный, стек.

Почему так происходит?

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

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

Что должен учитывать человек, принимающий решение

На что действительно стоит смотреть при выборе инструмента для production:

• Обкатанность. Используется ли в проде? Сколько лет? Где именно?

• Экосистема. Есть ли утилиты, плагины, интеграции?

• Сообщество. Есть ли люди, которым можно задать вопрос? Много ли открытых багов?

• Команда. Готовы ли ваши разработчики поддерживать это без боли?

• План Б. А что, если придётся отказаться? Есть ли миграционный путь?

Проверенное ≠ устаревшее

Часто слышу:

«Ну вы используете старье. Всё на Django, всё через PostgreSQL, сейчас же есть топовый ...»

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

Технологии — это не про «интересно». Это про ответственность.

Хочешь попробовать что-то новое? Прекрасно. Заводи pet-проект, играйся на хакатонах, делай эксперименты. Но в коммерческом продукте цена ошибки может быть бизнесу не по карману.

В завершение

Выбор стека — не фаза «для галочки». Это стратегическое решение. Оно должно отвечать на один вопрос: «Позволит ли это нам уверенно развиваться через 6, 12, 24 месяца?» Если да — пусть он будет хоть на Flask и jQuery. Если нет — вы просто тянете красивую бомбу с таймером.

Если вам близки такие разборы — я делюсь кейсами в Telegram‑канале «Техдир на пальцах»: без кода, без рекламы фреймворков — только практические ошибки и выводы из них.