Як прийняти сайт або застосунок від іншого розробника: що забрати насамперед

Підрядник, який зробив ваш сайт, магазин або застосунок, пішов чи перестав відповідати. Буває й простіше: він просто перестав вам підходити. А клієнти завтра зранку так само чекають, що все працюватиме. Розбираємо, чому передача проєкту зривається, що забрати в перший тиждень, що перевіряє аудит перед прийомом і як ми вирішуємо, що залишити, що оновити, а що переписати.

КОРОТКО

Як прийняти проєкт від іншого розробника

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

Фрилансер виходить на постійну роботу й починає відповідати раз на тиждень. Агенція змінює напрям. Або співпраця, що тривала роками, вичерпує себе, і ніхто заздалегідь не продумав, як вона закінчиться. У кожному з цих випадків сайт, магазин або застосунок далі приймає замовлення, заявки чи бронювання, а знання про те, як усе влаштовано, залишається в людей, які від проєкту вже далеко.

Ми приймаємо проєкти на Laravel, PHP, WordPress, Magento, React і Next.js, а також мобільні застосунки, і щоразу йдемо в одному порядку: доступи, робочі резервні копії, розуміння того, як зміни потрапляють у продакшен, далі аудит і лише потім рішення. У статті ми проходимо цей порядок на трьох наших проєктах: двічі правильною відповіддю виявилося оновлення і один раз повна переробка.

Проєкт, який не можна викотити без останнього розробника, належить вам не повністю.

ЧОМУ ЗРИВАЄТЬСЯ

П’ять причин, чому передача ламається

Майже кожен складний прийом проєкту, який ми бачили, зводиться до поєднання п’яти ситуацій. Злого наміру немає в жодній із них. Невелика команда працює швидко, тримає деталі в голові й збирається все записати в спокійний місяць, який так і не настає.

Доступи в однієї людини. Домен лежить в особистому акаунті розробника в реєстратора, хостинг оформлено на реселерський акаунт агенції, а Search Console підтверджено особистим токеном розробника. Для .com та інших загальних доменів реєстратор за правилами ICANN (Transfer Policy) зобов’язаний видати код перенесення власнику домену за записом протягом п’яти календарних днів після запиту. Якщо власник за записом ваш колишній підрядник, код отримає він.

Немає документації. На прохання надіслати документацію багато власників надсилають нам інструкцію для адмінки: як додати товар або опублікувати статтю в блозі. Новій команді потрібне інше: як пов’язані частини системи, як реліз потрапляє в продакшен, як відновитися після збою і які правила не видно з коду.

Немає тестової копії. Коли всі зміни вносять просто на живому сайті, оновлення не можна перевірити, не ризикуючи реальними замовленнями. Нова команда тоді отримує одразу дві проблеми: стару систему й відсутність безпечного місця, де її можна чіпати.

Невідомі версії. Ніхто не може сказати, яка версія PHP працює в продакшені і коли востаннє оновлювали фреймворк. Водночас дати публічні. PHP 7.4 перестав отримувати виправлення безпеки 28 листопада 2022 року, PHP 8.1 31 грудня 2025 року, а PHP 8.2 втратить їх 31 грудня 2026 року (php.net, жовтень 2026). Laravel дає кожній мажорній версії два роки виправлень безпеки, і Laravel 11 втратив їх 12 березня 2026 року.

Забуті інтеграції. Завдання за розкладом, яке щоночі надсилає прайс, вебхук у CRM, адреса зворотного виклику платіжного провайдера, форма, що досі копіює заявки людині, яка пішла два роки тому. Усе це працює, доки не перестане, і до того моменту ніхто не знає, що воно існує. Як володіння проєктом вислизає задовго до того, як розробник насправді йде, ми писали у статті Ваш сайт не падає в день, коли йде розробник.

ПЕРШИЙ ТИЖДЕНЬ

Чек-лист на перший тиждень

Перш ніж хтось відкриє бодай один файл із кодом, бізнесу потрібен контроль над тим, від чого цей код залежить. Ми проходимо з кожним власником ті самі вісім пунктів і для кожного записуємо, у кого він перебуває і на чиє ім’я оформлений.

Три пункти з цього списку створюють найбільше проблем, тож на них варто подивитися уважніше.

Репозиторій. Просіть передати репозиторій, а не завантажити його. На GitHub переданий репозиторій зберігає задачі, pull request і вікі, історія комітів залишається на місці, а посилання на стару адресу автоматично ведуть на нову (документація GitHub, жовтень 2026). Історія пояснює, чому код виглядає саме так, а архів файлів це пояснення викидає.

Резервна копія. Посібник CISA із захисту від програм-вимагачів вимагає регулярно перевіряти доступність і цілісність резервних копій у сценарії аварійного відновлення. Копію, яку жодного разу не відновлювали, ми вважаємо припущенням. Відновлення однієї копії в окремому середовищі відповідає одразу на два запитання: чи вона повна і скільки годин займе справжнє відновлення.

Паролі та ключі. Рекомендації OWASP щодо секретів сформульовано прямо: якщо секрет більше не потрібен або міг бути скомпрометований, його треба відкликати, і ніколи не повинно бути одного пароля на всіх адміністраторів. На практиці це означає замінити всі паролі та ключі, якими користувалася попередня команда, після того як доступи перейшли до вас, і того самого дня. Для Search Console потрібен ще один крок: за довідкою Google, щоб видалити підтвердженого власника, треба видалити і його токени підтвердження, інакше він зможе підтвердити сайт знову.

Ліцензії залишаються найнепомітнішим пунктом. Платні модулі часто купують на особистий акаунт розробника в маркетплейсі, і ліцензія, яку не можна продовжити, за рік перетворюється на модуль без оновлень безпеки.

РОЗСТАВАННЯ

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

Найлегше прийняти проєкт, коли попередня команда на зв’язку й готова допомогти. Більшість підрядників готові, якщо запит зрозумілий, а тон шанобливий, і спокійний вихід вартує більше за будь-яку суперечку про минуле.

1. Складіть список того, що у вас є, до будь-яких оголошень. Пройдіть таблицю першого тижня самостійно. Пункти, які ви не можете відкрити самі, треба запросити насамперед.
2. Прочитайте договір разом із юристом. Шукайте строк повідомлення, зобов’язання щодо передачі і те, кому належать код і акаунти. Юридичних консультацій ми не надаємо, але підкажемо, які технічні пункти мають бути закриті цими умовами.
3. Просіть доступи заради безперервності роботи, а не заради відходу. Додати компанію власником у реєстратора, на хостингу й у репозиторії вважається нормальним проханням на будь-якому етапі співпраці.
4. Надішліть один письмовий список, через себе. Ми готуємо його: репозиторій з історією, як зміна потрапляє в продакшен, налаштування середовища і завдання за розкладом, сторонні акаунти, відомі помилки та все, що вам обіцяли.
5. Запропонуйте оплатити дзвінок із передачі. Одна чи дві години, за які попередній розробник проведе нас системою, часто заощаджують дні читання коду.
6. Закрийте доступи в день, коли вони переходять. Паролі та ключі замінено, старі акаунти видалено, токени підтвердження видалено, і те саме правило діє, коли згодом іде будь-хто, зокрема ми.

Передача найлегше застрягає, коли залишаються питання щодо грошей, тож розрахуйтеся за виконану роботу до того, як підуть останні запити. Нехай кожен лист стосується знань, які вам потрібні, без оцінок якості попередньої роботи. Мета одна: робочий проєкт.

Холодний старт буває, коли ніхто не відповідає. Тоді ми починаємо з того, що бізнес контролює сам, з’ясовуємо, що можна повернути через реєстратора, хостинг-провайдера і кожен сервіс із підтвердженням володіння, а решту відновлюємо за сервером і кодом. Холодний старт триває довше й коштує дорожче, і це ще одна причина забрати доступи, доки стосунки добрі.

АУДИТ

Що перевіряє аудит перед прийомом

Коли доступи у вас, аудит у межах послуги прийому проєкту від іншого підрядника з’ясовує, що насправді працює. Він коштує від $2 500, і ціна фіксується до початку аудиту. Ціна зростає з розміром проєкту, кількістю інтеграцій і серверів, станом документації та обсягом доступів, які треба відновити: проєкт із попередньою командою на зв’язку й робочим репозиторієм прийняти дешевше, ніж холодний старт із доменом на чужому імені.

На проєкт дивляться три людини з різних боків:

• Розробник вивчає код: його структуру, застарілі чи покинуті залежності, проблеми безпеки та місця, які розумів лише попередній розробник.
• DevOps-інженер вивчає інфраструктуру: сервери, середовища, те, як ідуть викладки, і чи справді відновлюються резервні копії.
• Проєктний менеджер описує, як проєкт працює для бізнесу, його інтеграції та незавершену роботу, яку залишила попередня команда.

Аналіз коду за допомогою ШІ дає нам змогу читати чужий код набагато швидше, ніж кілька років тому. Він скорочує розвідку, але причини рішень і далі знаходять і записують люди, часто просто запитуючи власника, звідки взялося дивне правило.

Аудит шукає і збої, які нічого не показують на екрані. Форма може дякувати відвідувачам, а лист при цьому не надходить. Переїзд на інший хостинг може загубити записи SPF і DKIM і відправити заявки в спам. Налаштування хостингу за замовчуванням може закрити сайт від ШІ-краулерів. Тому кожен аудит містить реальну тестову заявку й перевірку поштової автентифікації, robots.txt і доступу краулерів.

До ціни аудиту входять збір доступів, письмовий звіт, документація щодо проєкту і дзвінок, на якому ми все розбираємо. Звіт ранжує ризики за терміновістю, дає вердикт щодо кожної частини проєкту і називає план і бюджет наступного етапу. Він належить вам: можна продовжити з нами або передати його будь-якій іншій команді. Термінові виправлення, знайдені дорогою, погоджуються з вами по одному й оплачуються окремо за ставкою нашої команди.

Аудит перед прийомом потрібен, коли бракує одразу двох речей: людей, які знали систему, і ясної картини того, що ви контролюєте. Якщо всі доступи у вас і застаріли лише версії, дешевше почати з аудиту в межах модернізації сайту: від $300 для невеликого сайту і від $1 000 для великого.

ЗАЛИШИТИ ЧИ ПЕРЕПИСАТИ

Залишити, оновити чи переписати

Кожна частина проєкту отримує свій вердикт, і переписування ніколи не є рішенням за замовчуванням. Інтернет-магазин може залишити каталог і адмінку як є, оновити фреймворк під ними й переписати одну інтеграцію, яка трималася на нічному скрипті.

Поріг у 60% ми використовуємо як емпіричне правило, а не як закон. Коли безпечне оновлення наближається до цієї частки вартості чистої розробки того самого, ми показуємо обидва варіанти поруч, з їхніми ризиками, і рішення ухвалює власник. Повний метод оновлення, з ринковими цінами та інструментами, описано у статті Оновлення старого сайту на Laravel чи PHP у 2026 році.

За кожним вердиктом стоїть те саме запитання: чи відповідає структура системи тому, як бізнес працює сьогодні? Версії можна виправити. Модель даних, побудована під бізнес, якого вже немає, переносить кожне старе рішення в нову версію, яким би акуратним не було саме оновлення.

ТРИ ПРОЄКТИ

Що ми вирішили на трьох реальних проєктах

Оновлення: шість версій Laravel на робочому сайті. Один із наших проєктів, який не був у пріоритеті, тримовний сайт із власною адмінкою та системою заявок, працював на Laravel 7 і PHP 7.4 і щодня робив свою справу. Ми перевели його на Laravel 13 і PHP 8.4 приблизно за три дні розробки, один день приймального тестування і п’ять хвилин запланованого простою. Три уроки з цього проєкту застосовні до будь-якого прийому. За понад 200 полями форм у 29 шаблонах стояв покинутий пакет форм; замість переписувати адмінку розробник написав невеликий шар сумісності. Початковий план відкату вказував на тег версії, створений до кількох днів сторонньої роботи, тож відкат скасував би і її; точку відкату перенесли на точний коміт продакшену. А кешування маршрутів, звичайна оптимізація швидкості, перетворило кожну сторінку тестової копії на 404, бо цей сайт будує мовні префікси з бази даних; правило «ніколи не кешувати маршрути» записали в письмові інструкції проєкту, щоб його не повторив жоден майбутній розробник чи ШІ-агент. Уся історія у статті Шість версій Laravel за три дні.

Оновлення: сайт і магазин медичного інституту. На сайті Інституту трихології ми довели стару збірку OpenCart до 3.0.5.1, останнього релізу лінійки OpenCart 3, а PHP до 8.3. Магазин інституту «Трихокосметика» був завершений багато років тому на PHP 5.6 і так і не запущений. Його дизайн досі виглядав гідно, а структура була здоровою, тому ми зберегли і те, і інше, перевели магазин на OpenCart 3.0.5.1 і PHP 8.4 та оновили модулі й інтеграції. Обидва сайти стали помітно швидшими, а вкладення в магазин вдалося використати замість того, щоб їх викинути.

Оновлюйте те, що бізнес зробив правильно. Переписуйте те, з чого він виріс.

Переробка: велика самописна система на PHP 5.3. В одного з наших клієнтів велика самописна система на PHP 5.3 з великою базою, що постійно змінюється. Підтримка безпеки PHP 5.3 закінчилася 14 серпня 2014 року (php.net). Система працює, але багато її зв’язків тримаються на обхідних рішеннях, які додавалися по одному впродовж років. Оновлення перенесло б кожне з них у нову версію, тому ми відрадили від нього й підписали договір на повну переробку. Зараз ми опрацьовуємо документацію разом з архітектором клієнта, щоб бізнес-процеси від самого початку були змодельовані правильно, а нова система була вибудувана довкола того, як компанія працює сьогодні, а не тоді, коли писалася перша версія.

Чому той самий старий стек блокує і ШІ-проєкти та як це змінює питання про оновлення, ми розібрали у статті ШІ-проєкт застряг на старій системі? Якщо систему, що вам дісталася, зібрали за допомогою ШІ-інструментів власник або невелика команда, у рішення своя логіка, про неї стаття Ви зібрали MVP за допомогою ШІ. Залишити, доопрацювати чи переписати?

ПЕРЕДАЧА

Що має входити в передачу проєкту

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

• Код у вигляді репозиторію з повною історією, щоб причини змін можна було простежити.
• Команди викладки: точні кроки, якими коміт потрапляє в продакшен, зокрема міграції бази й правила роботи з кешем.
• Вимоги до сервера: версія PHP і розширення, версія бази даних, завдання за розкладом, черги та назви налаштувань середовища (назви, а не значення в документі).
• Процедура відкату: як повернутися до попереднього релізу, з прив’язкою до точного коміту й перевіркою на копії: так ми враховуємо урок невірного тегу з прикладу вище.
• Файл AGENTS.md: короткий, написаний людиною опис структури, команд і жорстких правил проєкту.

Файл AGENTS.md читають ваші розробники, інший підрядник і ШІ-агенти для написання коду. Рядки з наших власних файлів показують, що має бути в ньому: ніколи не змінювати адресу наявної сторінки без 301-редиректу; ніколи не видаляти код, який виглядає невикористаним, не перевіривши вміст бази, скрипти за розкладом та інтеграції; на одному проєкті ніколи не кешувати маршрути. Навіщо потрібен такий файл і чому короткий кращий за довгий, ми пояснюємо у статті Вашому коду потрібна інструкція для ШІ.

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

Документація залишається єдиною частиною передачі, що працює після відходу всіх.

ДАЛІ

Як триває робота

Більшість проєктів після аудиту переходять на підтримку та обслуговування сайту від $1 000 на місяць: оновлення PHP, фреймворку та пакетів за графіком, щоденні резервні копії поза сервером із перевіркою відновлення, моніторинг і невеликі зміни всіма мовами, з оновленням документації після кожної зміни.

Нові функції та великі зміни оцінюються й отримують ціну до початку роботи. На Laravel і PHP це розробка на Laravel: $75 на годину або проєкт від $15 000. Продукту, який змінюється щотижня, підходить виділена команда розробки від $3 500 на місяць, зібрана з пулу перевірених людей, яких ми знаємо особисто. Сервери, конвеєри релізів, переїзд у хмару або черговий інженер поза робочим часом належать до роботи з DevOps і хмарної інфраструктури за ставкою від $50 до $70 на годину.

Якщо головне питання в тому, яким має стати продукт, а не в тому, у кого ключі, спершу проводиться стратегічна сесія. Вона триває від двох до трьох годин і готується заздалегідь; її вартість $500 зараховується в проєкт, який робимо ми. Усе подальше будується довкола того, як працює ваш бізнес: одне рішення замість дизайну, розробки й хостингу окремо. Код і розгортання передаються вам за договором. Усі наші ціни зібрані на сторінці цін, оплата банківським переказом за договором.

FAQ

Джерела

• PHP: Supported versions
• PHP: Unsupported branches
• Laravel: Release notes and support policy
• ICANN: Transfer Policy
• GitHub Docs: Transferring a repository
• OWASP: Secrets Management Cheat Sheet
• CISA: #StopRansomware Guide
• Довідка Google Search Console: власники, користувачі та дозволи