Почему команды со временем перерастают свой фреймворк

Что значит «перерасти фреймворк»

«Перерасти фреймворк» — это не про то, что фреймворк «плохой» или «устарел». Скорее, это про разрыв между текущими задачами продукта и тем набором допущений, ради которых фреймворк когда‑то выбрали.

На старте фреймворк почти всегда выигрывает: он задаёт структуру, ускоряет разработку типовых экранов и API, закрывает безопасность и авторизацию «из коробки», помогает быстрее нанимать людей под понятный стек.

Когда фреймворк помогает

Пока продукт развивается в рамках стандартного сценария (CRUD, умеренная нагрузка, простая доменная модель, несколько интеграций), фреймворк снимает массу организационных и технических решений. Команда тратит меньше времени на «как сделать» и больше — на «что сделать».

Когда он начинает тормозить

Проблема начинается, когда цена следования правилам фреймворка становится выше, чем польза от его готовых механизмов. Это не обязательно выражается в «чистой» производительности. Чаще — в скорости изменений, сложности поддержки, росте технического долга и количестве исключений из «правильного пути».

Практичный критерий: если заметная часть работы — это обход ограничений (хаки, обёртки, нестандартные паттерны, сложные плагины), то вы уже не используете фреймворк как ускоритель — вы его обслуживаете.

Какие решения доступны

Обычно есть четыре траектории:

• Остаться и принять ограничения как часть стратегии (если они не мешают бизнесу).
• Расширять: плагины, внутренние библиотеки, договорённости, рефакторинг вокруг «узких мест».
• Частично заменить: вынести отдельные модули/сервисы, заменить слой (например, ORM, роутинг, рендеринг), сохранив остальное.
• Мигрировать на другую платформу/фреймворк — когда стоимость обходов и риски уже системные.

Материал будет полезен тимлидам, продактам и архитекторам: он помогает отличить «нам просто не нравится» от ситуации, когда ограничения фреймворка реально начинают мешать масштабированию продукта и управляемости разработки.

Почему фреймворки так хорошо работают на старте

На ранней стадии продукта команда обычно решает одну задачу: как можно быстрее превратить идею в работающую версию и начать получать обратную связь. Фреймворк в этот момент экономит не только время, но и внимание — он снимает часть решений, которые иначе пришлось бы принимать «с нуля».

Быстрый старт: многое уже продумано

Большинство популярных фреймворков дают «из коробки» типовые вещи: маршрутизацию, структуру проекта, сборку, работу с формами, авторизацию (часто через готовые модули), интеграцию с базой, шаблоны UI.

Это особенно ценно, когда:

• требования ещё меняются и важно быстро перестраивать продукт;
• нет времени на архитектурные эксперименты;
• команда небольшая и у неё ограниченный опыт в проектировании платформ.

Фреймворк превращает первые итерации в последовательность понятных шагов, а не в набор разрозненных технических решений.

Отдельный вариант для старта и быстрых проверок гипотез — vibe-coding платформы вроде TakProsto.AI. Это другой подход: вместо того чтобы вручную собирать каркас приложения, вы описываете продукт в чате, а платформа помогает быстро получить веб/серверное/мобильное приложение, с возможностью выгрузки исходников и последующего развития командой.

Единый подход и предсказуемая структура

Фреймворк задаёт правила игры: где лежит логика, как именовать модули, как подключать зависимости, как писать тесты и конфигурировать окружения. Это снижает вариативность внутри команды: меньше споров о стиле, меньше ручных договорённостей.

В результате проще:

• онбордить новичков;
• делить задачи между людьми;
• поддерживать одинаковое качество в разных частях проекта.

Экосистема: ускоритель через готовые решения

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

Цена удобства: ограничения и «магия»

Все преимущества достигаются за счёт абстракций. Фреймворк скрывает детали и добавляет «магические» соглашения. На старте это плюс: меньше думать, быстрее двигаться.

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

Какие изменения в продукте «ломают» прежние предположения

Фреймворк почти всегда выбирают под текущий масштаб и ближайшие 6–12 месяцев. Он «предполагает», что нагрузка умеренная, команда небольшая, доменная логика относительно простая, а требования к надежности и интеграциям — терпимы. Когда продукт растёт, эти исходные допущения перестают быть правдой — и тогда проблема уже не в «плохом фреймворке», а в изменившейся реальности.

Рост нагрузки: не просто «больше пользователей»

Первые трещины появляются, когда возникают пики: акции, рассылки, сезонность. Добавляются очереди, фоновые задачи, отчёты, обработка файлов, вебхуки и новые интеграции.

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

Рост команды: параллельная разработка и владение

То, что работало для 3–5 человек, часто ломается на 15–30: больше веток, больше конфликтов, сложнее код‑ревью, требуется понятное разделение модулей и ответственности.

Когда границы в коде размыты, фреймворк невольно поощряет «общие места» и сквозные зависимости. В результате любое изменение затрагивает чужие части системы, а скорость падает.

Рост домена: правила, контуры, роли

С усложнением продукта появляются исключения, тарифы, согласования, несколько «контуров» (например, для разных стран или юридических лиц), сложные роли и права.

Если фреймворк ориентирован на простую CRUD‑логику, доменные правила начинают расползаться по контроллерам, хукам, моделям и шаблонам — становится трудно гарантировать корректность.

Рост требований к качеству: SLA, наблюдаемость, безопасность

Как только появляются SLA, аудит, комплаенс, требования к логированию, трассировке и управлению доступами, выясняется, что «по умолчанию» многие вещи не предусмотрены или неудобны.

Нужно не только «чинить баги», а уметь быстро отвечать на вопросы: что сломалось, почему, кого затронуло, как предотвратить повтор.

Рост каналов: веб, мобильные, партнёры

Когда к вебу добавляются мобильные клиенты и партнёрские API, растут требования к стабильности контрактов, версионированию, лимитам, совместимости и документации.

Если фреймворк хорошо чувствует себя в одном канале, то мультиканальность заставляет пересмотреть архитектуру: где находится бизнес‑логика, как она переиспользуется и как защищается от изменений интерфейсов.

Признаки, что фреймворк начал тормозить

Иногда проблема не в людях и не в процессе, а в том, что выбранный когда-то фреймворк перестал соответствовать масштабу и устройству продукта. Это редко проявляется одной большой аварией — чаще накапливаются характерные симптомы.

1) Скорость разработки падает, хотя команда выросла

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

Практический маркер: растёт доля задач «на поддержку» (починка, согласование зависимостей, ручные проверки) по отношению к задачам, которые дают пользователю ценность.

2) Любое изменение запускает каскад побочных эффектов

Вы правите одну форму или один endpoint — и внезапно ломаются другие части системы, потому что всё завязано на общие состояния, глобальные middleware, «магические» хуки или неочевидные правила фреймворка.

Это часто выглядит так:

• правка в одном модуле требует изменений в трёх–пяти соседних;
• тесты падают в местах, не связанных с задачей;
• разработчики боятся «трогать» определённые файлы/пакеты.

3) Появляется много обходных путей и нестандартных паттернов

Когда «как задумано» перестаёт работать, команда начинает изобретать обходы: собственные контейнеры, ручной роутинг поверх встроенного, кастомные слои кеширования, дублирование моделей. Один‑два таких приёма допустимы. Но если они становятся нормой, фреймворк уже не помогает, а мешает.

Характерный признак — новичку проще понять внутренний «командный фреймворк», чем официальный подход.

4) Обновления фреймворка становятся рискованными и постоянно откладываются

Если апдейт минорной версии превращается в проект на месяц с неизвестным результатом, значит у вас накопилось слишком много завязок на внутренние детали и устаревшие расширения.

Косвенные сигналы: зависимость от плагинов без поддержки, необходимость держать старую версию runtime, частые «заморозки» разработки перед обновлением.

5) Разрыв между «как надо по фреймворку» и тем, как реально работает система

Команда всё чаще говорит: «по документации нужно так, но у нас иначе». Появляются правила, которые нигде не написаны, кроме внутренних заметок. Это создаёт постоянное трение: больше ревью ради соблюдения стиля, больше споров о «правильном» способе и меньше уверенности в предсказуемости результата.

Если вы узнаёте себя хотя бы в трёх пунктах, это сигнал не к панике, а к диагностике: что именно ограничивает — архитектура, экосистема, производительность или поддерживаемость кода.

Типовые причины: где начинаются ограничения

Фреймворк почти всегда предлагает «правильный» способ делать вещи — и это помогает держать темп на старте. Но по мере масштабирования продукта те же механики начинают превращаться в ограничения: вы тратите больше времени на обходные пути, чем на ценность для пользователей.

1) Жёсткие соглашения и «золотой путь»

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

2) Скрытая сложность: зависимости и «магия»

Многие фреймворки экономят время за счёт неявных зависимостей (автоматическая инъекция, глобальные контексты, конвенции поверх конфигурации). Со временем это мешает: изменения в одном месте неожиданно ломают другое, онбординг новых людей усложняется, а отладка превращается в угадайку. Такой vendor lock‑in проявляется не только в инструментах, но и в образе мышления команды.

3) Производительность и ограниченная настройка

Проблемы производительности приложения часто начинаются не с «медленного кода», а с лишних абстракций и невозможности тонко настроить критические участки: кеширование, очереди, пул соединений, сериализацию, рендеринг. На раннем этапе это незаметно, но при росте нагрузки и требований по SLA становится системным тормозом.

4) Тестируемость как сигнал зрелости

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

5) Vendor lock-in: решения расползаются по коду

Чем больше бизнес‑логики завязано на специфичные для фреймворка сущности (аннотации, middleware, lifecycle‑хуки), тем дороже миграция технологий и тем сложнее обсуждать переход на другую платформу — будь то реорганизация монолита и микросервисов или просто смена слоя хранения/коммуникаций.

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

Фреймворк обычно рассчитан на «средний» продукт: стандартные запросы, простые роли, понятные интеграции, предсказуемые релизы. Пока вы укладываетесь в эти рамки — всё отлично. Но по мере роста продукта требования начинают «выпирать» из модели, которую фреймворк предполагает по умолчанию. В этот момент команда тратит всё больше времени не на развитие, а на обход ограничений.

Наблюдаемость становится обязательной

На старте хватает базовых логов и мониторинга ошибок. Дальше появляются цепочки из нескольких сервисов, очередей и фоновых задач — и без трассировки и корреляции запросов становится трудно понять, где именно «горит».

Если фреймворку сложно добавить единый request‑id, разнести метрики по бизнес‑операциям и связать логи/трейсы в один сценарий, вы начинаете отлаживать «вслепую». Это не только боль инженеров — это задержки в поддержке клиентов и рост времени восстановления.

Интеграции перестают быть «плагином»

Когда появляются очереди, шины событий, несколько сторонних сервисов и SSO, важны идемпотентность, повторная доставка сообщений, ретраи, дедупликация, таймауты, контуры безопасности. Если фреймворк заточен под синхронный запрос‑ответ и «тонкие» интеграции, приходится строить инфраструктуру рядом: отдельные воркеры, хранилища состояния, собственные адаптеры.

Мультиарендность и доменные права

«Роли и права» быстро усложняются до разграничения на уровне домена: tenant → организация → подразделение → проект → объект. Появляются требования к изоляции данных, отдельным лимитам, настройкам и даже разному поведению бизнес‑логики.

Если фреймворк не поддерживает такие правила как часть модели (а не как набор if‑ов), возрастает риск утечек данных и ошибки в доступе становятся системными.

Релизы усложняются

Когда релизы идут часто и на большую аудиторию, нужны фича‑флаги, канареечные выкладки, постепенное включение, быстрый откат и обратная совместимость API/схем. Фреймворк может не мешать, но и не помогать: например, миграции БД «ломают» старые версии приложения, а клиентские SDK не успевают обновляться.

Появляется необходимость в модулях и контрактах

Рост команды и функциональности требует разделения на модули/сервисы с чёткими контрактами: версионирование API, правила совместимости, контрактные тесты, события как публичный интерфейс.

Если фреймворк подталкивает к единому монолитному ядру и общему состоянию, модульность становится проектом по «разминированию» зависимостей. Тогда вопрос уже не «переписать или нет», а «как организовать границы и контракты так, чтобы продукт продолжал расти».

Как оценить цену: не только скорость разработки

Когда обсуждают смену фреймворка или серьёзную модернизацию, разговор быстро сводится к «скорости разработки». Это важно, но часто не главное. Полезнее считать общую стоимость владения: что команда платит деньгами, временем и рисками за текущий выбор.

Бизнес: сколько стоит «сейчас» и сколько может стоить «потом»

Оцените влияние фреймворка на time‑to‑market: сколько дней/недель уходит на типовую фичу, сколько времени «съедают» обходные решения и ручная работа.

Отдельно посчитайте цену простоя и деградаций: даже редкие инциденты могут стоить дороже, чем месяц разработки. Полезно завести понятные категории: прямые потери (выручка, штрафы, компенсации) и косвенные (репутация, рост оттока, срыв партнёрств).

Техметрики: где прячется реальная стоимость

Соберите метрики, которые напрямую конвертируются в затраты:

• время сборки и деплоя (часы людей + задержка релизов);
• число инцидентов и повторяемость причин;
• частота откатов и доля «горячих» фиксов;
• производительность приложения (ресурсы инфраструктуры, стоимость масштабирования).

Важно смотреть не на абсолютные числа, а на тренд: если каждый квартал сборка растёт на 20%, это будущая блокировка скорости.

Кадры: найм, обучение и цена «нестандартности»

Если стек стал редким или сильно кастомизированным, растут расходы на найм и адаптацию: дольше закрываются вакансии, выше нагрузка на менторов, больше ошибок у новичков. Добавьте сюда риск текучести, когда люди устают поддерживать «самописные» решения вместо развития продукта.

Экосистема: обновления, зависимости и безопасность

Проверьте активность обновлений, совместимость ключевых библиотек и скорость закрытия уязвимостей. Если обновления превращаются в проект на несколько недель или упираются в несовместимости, это уже постоянная статья расходов.

Зафиксируйте критерии успеха заранее

До начала изменений сформулируйте измеримые критерии: например, «сборка ≤ 10 минут», «релиз без отката в 95% случаев», «время на типовую фичу −30%», «обновления зависимостей раз в 2 недели без форс‑мажоров». Без них обсуждение цены неизбежно скатится в субъективные ощущения.

Варианты действий: от улучшений до миграции

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

1) Остаться и навести порядок

Иногда проблема не во фреймворке, а в том, как он используется.

• Уберите «магические» части: неочевидные хуки, метапрограммирование, скрытые зависимости.
• Введите чёткие границы модулей, единый стиль архитектуры и соглашения.
• Закройте техдолг, который напрямую бьёт по скорости: тесты на критические сценарии, упрощение сложных участков, обновление зависимостей.

Это лучший вариант, если продукт растёт, но основные ограничения — в поддерживаемости кода и предсказуемости изменений.

2) Расширить: плагины и слой домена поверх

Если фреймворк в целом подходит, но не закрывает часть требований, можно «достроить» недостающее:

• написать свои модули/плагины;
• сделать адаптеры к внешним системам;
• добавить доменный слой поверх фреймворка, чтобы бизнес‑логика меньше зависела от деталей платформы.

Так вы снижаете связанность: со временем становится проще заменить инфраструктурные части без переписывания всего приложения.

3) Частичная замена: вынести проблемные зоны

Часто тормозит не весь продукт, а конкретные компоненты. Тогда разумно вынести «больные» места в отдельные сервисы/приложения, например:

• публичный API;
• фоновые задачи и очереди;
• поисковый индекс;
• тяжёлые отчёты.

Это даёт быстрый эффект по производительности и надёжности при умеренной цене.

4) Полная миграция — только при чётких выгодах

Полная смена фреймворка/платформы оправдана, когда ограничения системные (производительность, модель данных, безопасность, эксплуатация) и их невозможно устранить иначе. Важно заранее зафиксировать измеримые выигрыши: какие метрики улучшатся и когда — иначе миграция рискует стать бесконечным проектом.

План перехода без остановки разработки

Переход на другую платформу или существенная переработка архитектуры редко удаются «большим взрывом». Почти всегда выгоднее план, который позволяет выпускать фичи и параллельно менять фундамент. Цель простая: пользователи не замечают изменений, а команда контролирует риск и темп.

1) Стратегия «удушающей лозы»

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

2) Выделите границы и контракты

Прежде чем переписывать, договоритесь о границах:

• модули и зоны ответственности;
• контракты (API, события, форматы сообщений);
• анти‑коррупционный слой, который переводит «старые» модели в «новые», чтобы технический долг не проникал дальше.

Это снижает стоимость миграции технологий: изменения локализуются, а поддерживаемость кода растёт ещё до полного перехода.

3) План данных: совместимость и обратные изменения

Данные обычно сложнее кода. Нужен отдельный план:

• миграции схем маленькими шагами;
• совместимость чтения/записи между версиями;
• обратные изменения (возможность отката), чтобы релизы не превращались в рискованную лотерею.

Если предполагается разделение монолита и микросервисов, заранее определите владельца данных и правила синхронизации.

4) Релизы без остановки: параллельный запуск

Рабочий подход: запустить новую реализацию параллельно и управлять трафиком.

• маршрутизация по флагам/процентам/группам;
• сравнение результатов (где возможно);
• быстрые откаты на старый путь.

Практический приём, который помогает снизить риск, — заранее обеспечить «страховочные механики» вроде снапшотов и быстрого отката. Например, в TakProsto.AI для приложений есть snapshots и rollback, что удобно для пилотов и экспериментальных веток: можно проверять гипотезы, не превращая каждое изменение в дорогую операцию.

5) Список «не трогать сейчас»

Чтобы не утонуть в бесконечной переделке, зафиксируйте стоп‑лист: какие части системы не переписываем до явного триггера (рост нагрузки, изменение требований, критические дефекты). Это защищает скорость разработки и удерживает фокус на том, что реально ограничивает масштабирование продукта.

Типовые риски и как их снизить

Переход с одного фреймворка на другой (или радикальная переработка текущего) редко «ломается» из‑за одной ошибки. Обычно проблемы накапливаются: растёт объём работ, появляется параллельная поддержка двух подходов, а команда теряет ясность — что уже решено, а что ещё обсуждается.

Риск «вечной миграции»

Самый частый сценарий: миграция превращается в бесконечный фон, который съедает время и мотивацию.

Снизить риск помогают три правила: фиксируйте объём (что именно переносим и что точно не переносим), задавайте контрольные точки (например, каждые 2–4 недели) и заранее определите «точки принятия решений» — моменты, когда можно остановиться, изменить стратегию или сузить цель.

Неполная совместимость: API, сообщения, транзакции

Даже если новый стек «умеет то же самое», детали часто расходятся: контракты API, форматы сообщений, обработка ошибок, семантика транзакций.

Практика: формализуйте контракты (OpenAPI/JSON Schema), добавьте контрактные тесты и введите режим совместимости (версионирование API, адаптеры, временные шлюзы). Для транзакций заранее договоритесь о допустимом уровне согласованности данных и опишите, где возможна «временная рассинхронизация».

Скрытая зависимость от фреймворка

Зависимость прячется не только в коде, но и в шаблонах, middleware, соглашениях об именовании, способах авторизации.

Действие: составьте карту зависимостей и выделите «границы» — слой адаптеров/интерфейсов, через который бизнес‑логика общается с фреймворком. Чем раньше вы изолируете эти места, тем дешевле последующие шаги.

Снижение качества на переходе

В период изменений чаще растут баги и регрессии.

Усильте тесты на критические сценарии, добавьте мониторинг ошибок и ключевых метрик, а также договоритесь о правилах: код‑ревью, критерии готовности, запрет на «быстрые хаки» без задачи на устранение.

Коммуникация и владение решением

Если не ясно, кто владелец решения, обсуждения становятся бесконечными.

Назначьте ответственного (техлида/архитектора/группу), фиксируйте договорённости письменно (ADR или короткие заметки) и держите единый статус‑документ: что решено, что в работе, какие риски открыты и когда следующее пересмотрение.

Практический чек‑лист: что сделать в ближайшие 30 дней

Ниже — план на 4 недели, который помогает понять, действительно ли происходит перерастание фреймворка, и что делать дальше без резких движений.

1) Зафиксируйте симптомы и договоритесь, как их измерять

Соберите 6–10 наблюдаемых признаков и привяжите к ним метрики. Примеры:

• время вывода фичи: lead time от задачи до релиза;
• количество «обходных путей» в коде: временные костыли, флаги, исключения из правил;
• производительность: p95/p99 по ключевым эндпоинтам, время старта, потребление памяти;
• надёжность: частота инцидентов, MTTR, количество откатов;
• качество: доля изменений без тестов, число регрессий.

Критерий решения задайте заранее: например, «если 2–3 метрики стабильно ухудшаются 3 спринта подряд, запускаем пилот и план миграции».

2) Соберите «карты боли» (3–5 пунктов)

Сделайте короткий документ на одну страницу: где именно фреймворк мешает и сколько это стоит.

Пример карты боли:

1. Ограничения в модульности → сложно изолировать изменения, растут регрессии.
2. Слабая наблюдаемость «из коробки» → долго ищем причины инцидентов.
3. Проблемы с производительностью на пике → упираемся в архитектурные допущения.
4. Интеграции/очереди/фоновые задачи делаются «в обход» → растёт технический долг.
5. Сложность тестирования → тесты медленные или нестабильные.

3) Запустите пилот на новом подходе

Выберите небольшой модуль/сервис с понятными границами (например, импорт данных или отдельный API) и реализуйте его по новой схеме. У пилота должен быть измеримый результат: скорость разработки, стабильность, p95, удобство поддержки.

Если цель пилота — именно скорость сборки прототипа и проверка требований (а не идеальная архитектура с первого дня), можно рассмотреть TakProsto.AI как «песочницу»: в режиме planning mode удобно фиксировать требования и ограничения до реализации, а затем при необходимости выгрузить исходный код и продолжить развитие уже в привычном пайплайне. Это особенно полезно, когда вы параллельно сравниваете несколько вариантов архитектуры.

4) Договоритесь о стандартах до расширения эксперимента

Минимальный набор: структура проекта, правила зависимостей, тестирование (unit + интеграционные), наблюдаемость (логи/метрики/трейсы), политика версионирования и деплоя. Это снижает цену изменений и помогает поддерживаемости кода.

5) Подготовьте решение для руководства и команды

Сведите всё в таблицу «вариант → выгоды → риски → стоимость»: улучшение текущего стека, частичная миграция, постепенный переход на другую платформу.

Чтобы прикинуть бюджет и сценарии, удобно сверяться с коммерческими условиями (/pricing) и подборками практик/кейсов (/blog).

Если вы рассматриваете путь через ускорение разработки (без отказа от инженерных практик), заранее зафиксируйте организационные требования: где будет хостинг, как устроен доступ к данным, возможен ли экспорт исходников, как делаются откаты и кто владеет инфраструктурой. В этом смысле TakProsto.AI часто воспринимают как прагматичное дополнение к классическому программированию: быстро собрать приложение на React + Go + PostgreSQL, развернуть, а затем уже решать, какой объём развивать внутри платформы, а какой — в собственном репозитории.