День запуску отримує всю увагу. Але перші 30 днів після запуску — це період, коли проєкти або стабілізуються, або починають сипатися. Більшість проблем, які я виправляв у rescue-проєктах, не були багами, що існували на запуску — вони з'являлися на другому тижні, коли реальні користувачі робили те, що ніхто не тестував.
Ось 30-денний план, який я запускаю на кожному клієнтському проєкті. Якщо ваш розробник не пропонує щось подібне — попросіть.
Тиждень 1 (дні 1–7): спостерігаємо за всім
Мета першого тижня проста: зловити те, що пропустило тестування.
День 1: smoke-тест продакшну. Не стейджингу — продакшну. Прогоніть пункти 13, 18, 19, 20 і 23 передзапускового чекліста по живому URL. Перевірте платіжний флоу реальною карткою. Переконайтеся, що трекінг помилок отримує події, а не просто налаштований.
Дні 2–3: моніторимо обсяг помилок. Перші 48 годин реального трафіку розкриють проблеми, які автотести ніколи не ловлять. Правильно налаштований трекер помилок має фільтрувати шум і алертити про реальні проблеми. Перевіряйте його двічі на день.
Дні 4–7: збираємо точки тертя. Не запити фіч — точки тертя. Де користувачі застрягають? Де звертаються до підтримки? Де йдуть? Якщо є аналітика — дивіться воронку. Якщо немає — запитайте перших 10 користувачів напряму: «Що вас заплутало?»
Результат: ранжований список знайдених проблем, категоризованих як критичні (блокують використання), важливі (погіршують досвід) або незначні (косметичні). Критичні — виправляємо того ж дня. Важливі — на другий тиждень.
Тиждень 2 (дні 8–14): виправляємо і заміряємо
Перший тиждень — спостереження. Другий — дія.
Виправляємо важливі проблеми з першого тижня. Не запити фіч — точки тертя. Кнопка, що не працює в Safari. Форма, яка таймаутить на повільному з'єднанні. Лист, що потрапляє в спам. Це те, що втрачає користувачів на першому тижні.
Встановлюємо базові метрики продуктивності. Запускаємо Lighthouse на 5 найвідвідуваніших сторінках. Фіксуємо Core Web Vitals із даних реальних користувачів (не лабораторних тестів). Фіксуємо час відповіді API на p50 та p95. Ці числа — базова лінія: з ними ви порівнюватимете на 2-му, 6-му, 12-му місяці.
Перевіряємо серверні витрати проти прогнозів. Якщо ви закладали €30/міс на хостинг, а бачите €90 після тижня реального трафіку — розбирайтеся зараз. Часті винуватці: неоптимізовані запити до БД, відсутність оптимізації зображень, серверлесс-функції з частим cold start.
Результат: усі критичні та важливі проблеми вирішені. Документ з базовими метриками: продуктивність, рівень помилок, вартість хостингу.
Тиждень 3 (дні 15–21): крайові випадки і масштаб
До третього тижня очевидні проблеми виправлені. Тепер шукаємо, що ламається під навантаженням.
Крайові випадки. Що відбувається, коли користувач відправляє форму двічі? Якщо відкриває застосунок у двох вкладках? Якщо в нього 500 елементів замість 10, на яких ви тестували? Якщо в імені апостроф? Це не гіпотетичні сценарії — це проблеми, які спливають на масштабі.
Патерни навантаження. Якщо у продукту передбачувані піки трафіку (понеділок вранці для B2B-інструменту, вечори для споживчого застосунку) — моніторте ці періоди окремо. Перевірте, що підключення до БД не вичерпуються, rate limits налаштовані правильно, кешування працює.
Зовнішні залежності. Перевірте аптайм та продуктивність кожного зовнішнього сервісу: платіжний провайдер, email-сервіс, аналітика, CDN. Якщо хтось із них мав інцидент у перші два тижні — переконайтеся, що обробка помилок справді спрацювала.
Результат: виправлення крайових випадків задеплоєні. Нотатка про будь-які проблеми масштабування, які потрібно вирішити до наступної віхи трафіку (10× поточних користувачів).
Тиждень 4 (дні 22–30): передача та план обслуговування
Четвертий тиждень — про те, щоб проєкт виживав без режиму кризи.
Оновлення документації. Оновіть README, гайд з деплою та runbook-и з тим, що дізналися за тижні 1–3. Продакшн-конфігурація напевно відрізняється від запланованої — задокументуйте фактичний стан.
Налаштування моніторингу. На цей момент ви знаєте, які помилки реальні, а які — шум. Налаштуйте пороги алертів. Приберіть хибні спрацьовування. Налаштуйте щотижневий email-дайджест помилок, щоб ловити регресії без щоденних перевірок.
Аудит залежностей. Запустіть перевірку безпеки залежностей. Налаштуйте автоматичні алерти (Dependabot, Renovate) для критичних вразливостей. Не потрібно оновлювати все — просто переконайтеся, що дізнаєтеся, коли щось потребуватиме уваги.
План обслуговування. Визначте, як виглядає поточна підтримка:
- Хто моніторить помилки? Як часто?
- Який час реакції на критичні баги?
- Коли оновлюватимуться залежності?
- Хто обробить наступну віху трафіку?
Результат: односторінковий план обслуговування. Не контракт — спільне розуміння того, що значить «підтримувати це в робочому стані».
Скільки це коштує
30-денна стабілізація зазвичай займає 15–25 годин розробника, розподілених на місяць. Для проєкту з вартістю збірки €10K–€20K — це приблизно €1,500–€3,000 на постзапускову підтримку.
Порівняйте з вартістю запобіжного аутейджу на 2-му місяці, прогалини в GDPR-комплаєнсі, виявленої скаргою користувача, або регресії продуктивності, яка вбиває конверсію перш ніж ви зібрали достатньо даних для діагностики.
Кожен rescue-проєкт, з яким я працював, не мав періоду стабілізації. Розробник зашипив, відправив фінальний рахунок і зник. Через два місяці фаундер шукав когось, хто полагодить те, що зламалося.
Питання, яке варто задати розробнику
Перед запуском запитайте: «Як виглядають перші 30 днів після запуску?»
Якщо відповідь «будемо лагодити баги по мірі надходження» — це не план. Це надія, що нічого не зламається.
Якщо відповідь — структурований потижневий підхід з конкретними результатами — ви працюєте з тим, хто вже шипив і знає, що буває далі.
Плануєте запуск і хочете, щоб структурована стабілізація була частиною проєкту? Напишіть — постзапускова підтримка — частина кожного проєкту, який я шиплю, а не запізніла думка.