Перші дні
Спочатку не код, а доступи. Сервери, домен, база даних, репозиторій, поштові сервіси, платіжні системи, хмарні акаунти: усе, що оплачувалось із картки розробника або було зареєстровано на його пошту, треба перевести на компанію. Це нудно, але саме тут проєкти зникають насправді: не через поганий код, а через домен, який не продовжили.
Паралельно бекап усього, до чого є доступ. Навіть якщо бекапи «десь є», зробіть свіжий і перевірте, що він відкривається.
Що ми робимо перші два тижні
Забираємо код у репозиторій, якщо його там немає. Піднімаємо проєкт локально й записуємо, як це робиться: це перша сторінка документації, якої ніколи не було. Дивимось, як відбувається деплой, і робимо його повторюваним. Ставимо моніторинг помилок, щоб дізнаватись про проблеми раніше за користувачів.
Потім аудит: що в системі критичного, що зламано вже зараз, що зламається за місяць. Результат у вигляді документа з варіантами дій. Із ним ви розумієте, чи потрібна вам постійна команда, чи один розробник у штаті, чи достатньо кількох годин підтримки на місяць.
Чи треба шукати «такого самого»
Зазвичай ні. Якщо система написана на стандартному Laravel або Symfony, будь-який розробник із ринку розбереться в ній за тиждень, і ми допоможемо йому це зробити. Якщо система написана на власному фреймворку попереднього розробника, шукати людину з тими самими знаннями безглуздо: її немає. Тоді питання в тому, як привести код до стану, коли його зможе вести хтось інший. Це і є наша робота.
Чого не варто робити
Не варто наймати першого, хто погодиться, і давати йому продакшен-доступи в перший день. Не варто починати переписування з нуля, поки система працює і приносить гроші. Не варто ігнорувати ситуацію, сподіваючись, що нічого не зламається: щось зламається, питання лише коли.
Як це закінчується
Через кілька тижнів у вас є репозиторій, документація, повторюваний деплой і розуміння стану системи. Далі або ми ведемо підтримку, або ви наймаєте розробника, і він отримує проєкт, у який можна увійти. Обидва варіанти нормальні.