Як ми рятуємо недопиляні кодові бази без переписування з нуля

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

Тиждень 1: читати, не писати

Ми нічого не зливаємо в main протягом п'яти робочих днів. Ми читаємо. Кожен файл, кожну міграцію, кожен commit message. Запускаємо npx depcheck, перевіряємо bundle size, відкриваємо консоль Firebase, перераховуємо всі зовнішні сервіси, знімаємо snapshot всіх env-змінних.

Результат: 5-сторінковий audit-документ. Що працює, що зламано, що ризиковано, чого бракує. Ділимося з клієнтом на дзвінку, не в email.

Тиждень 2: стабілізувати mainline

• CI запускається на кожному PR.
• Typecheck проходить.
• Preview-деплої на кожному PR.
• Error tracking (Sentry) ловить prod-помилки.
• Критичні шляхи отримують Playwright smoke-тести.

Якщо застосунок навіть не стартує — це фіксимо першим. Якщо стартує, але ламається на масштабі — додаємо load-тест. До кінця другого тижня merge'и знову безпечні.

Тижні 3–N: випустити backlog

Тепер ми йдемо звичним Run-ритмом: тижневий реліз, рев'ю через preview, цикл зворотного зв'язку через аналітику. Клієнти, що приходять у паніці, зазвичай досягають спокійної передбачуваності до 4-го тижня.

Чого ми НЕ робимо

Ми не переписуємо заради переписування. Ми не міняємо фреймворки. Ми не «модернізуємо» код, що не створює проблеми. Найшвидший спосіб закінчити проєкт — зазвичай закінчити проєкт.