Нестабільна помилка
Проблема виникає не завжди або залежить від сценарію.
Technical analysis
Спочатку розбираємося, потім рекомендуємо
Аналізуємо сайт, код, модулі, інтеграції та серверне оточення, щоб зрозуміти причини проблем, ризики й реальний обсяг майбутніх змін.
Не даємо рекомендації «наосліп» — дивимося, як проєкт реально працює.
Existing project→Technical analysis→Risks / Priorities→Action plan
Коли це потрібно
Коли опису проблеми недостатньо для оцінки
Аудит — не самоціль: він має допомогти прийняти технічне рішення.
Legacy-код
Логіка розподілена між старими модулями та файлами.
Чужий проєкт
Потрібно продовжити роботу після іншої команди.
Складна інтеграція
Потрібно зрозуміти поточний обмін даними.
Велике доопрацювання
Важливо оцінити ризик змін у діючому проєкті.
Міграція
Потрібна карта функціоналу, даних та інтеграцій.
Прийняття на підтримку
Перед супроводом потрібно зрозуміти стан проєкту.
Повторювані проблеми
Потрібно знайти причину, а не виправити симптом.
Обсяг
Що саме перевіряємо — залежить від задачі
Код і архітектура
- структура проєкту
- custom code
- hooks/events
- дублювання логіки
- залежності
- hardcode
CMS та модулі
- версія CMS
- тема/шаблон
- плагіни
- сумісність
- конфлікти
- точки розширення
Інтеграції
- CRM і KeyCRM
- API
- webhooks
- платежі
- доставка
- custom integrations
Дані
- таблиці
- external IDs
- зв’язки
- дублікати
- статуси
- каталог і замовлення
Фонові процеси
- cron
- scheduled jobs
- queues
- imports
- synchronization
- recurring scripts
Інфраструктура
- PHP
- web server
- database
- storage
- logs
- конфігурація
Перед доопрацюванням
Щоб оцінити зміни, потрібно зрозуміти реалізацію
Задача → Аналіз коду → Точка зміни → Ризики → Оцінка → Реалізація
Доопрацювання сайтів →Якщо задача проста й реалізація очевидна — окремий аудит може бути не потрібен.
Integration layer
Проблема може бути між сайтом і зовнішньою системою
Подія → Інтеграція → API → Відповідь → Оновлення даних
API-інтеграції →- webhook
- API request
- authorization
- payload
- mapping
- IDs
- duplicates
- logging
- cron
- error handling
- retry
- status mapping
- API version
Відтворення
Спочатку потрібно побачити проблему технічно
Відтворюємо → знаходимо точку помилки → перевіряємо дані → визначаємо причину.
Продуктивність
Повільний сайт не завжди потребує нового сервера
Не обіцяємо конкретний PageSpeed без вимірювань.
Безпека
Помітні технічні ризики також фіксуємо
Це не penetration test, не сертифікація і не повний security audit. Не гарантуємо пошук усіх вразливостей.
- застарілі CMS і модулі
- debug mode
- секрети в коді
- відкриті endpoints
- небезпечні права
- очевидні проблеми конфігурації
Технічний борг
Не кожну стару частину коду потрібно переписувати
Мета — визначити пріоритети, а не скласти найдовший список проблем.
Критично
Ризик даним, процесу або подальшому розвитку.
Бажано
Не блокує, але здорожчує наступні зміни.
Можна залишити
Працює стабільно й не потребує переписування заради чистоти.
Результат
На виході потрібен план дій, а не список зауважень
Формат залежить від обсягу: повідомлення, висновок, checklist, markdown/doc, backlog або окремий звіт. Великий PDF не є обов’язковим результатом кожного аудиту.
- опис реалізації
- причина проблеми
- список ризиків
- критичність і залежності
- варіанти рішення
- рекомендований підхід
- порядок робіт
- попередня оцінка етапів
- питання для додаткової перевірки
Правильний формат
Аудит чи діагностика конкретної проблеми
Діагностика
Одна помилка, один сценарій або одна інтеграція — потрібно знайти причину.
Технічний аудит
Багато пов’язаних проблем, великі зміни, legacy-проєкт або міграція.
Не продаємо великий аудит, якщо достатньо локальної діагностики.
Платформи
Сайт не обов’язково має бути розроблений PromoSite
- WordPress
- WooCommerce
- Bitrix
- OpenCart / ocStore
- PrestaShop
- Laravel
- Symfony
- CodeIgniter
- Custom PHP
- Інші проєкти після аналізу
Старт
Починаємо з питання, на яке аудит має дати відповідь
Спочатку визначаємо мету, щоб не аналізувати те, що не впливає на рішення.
Описати задачу- URL сайту
- CMS, якщо відома
- опис проблеми або задачі
- чому потрібен аудит
- що потрібно отримати
- логи, скріншоти або приклади
- доступи — після погодження обсягу
Процес
Як відбувається технічний аудит
- 01
Фіксуємо питання
Що саме потрібно з’ясувати.
- 02
Отримуємо контекст
Сайт, код, CMS, логи та інтеграції.
- 03
Аналізуємо реалізацію
Код, модулі, дані, API та infrastructure.
- 04
Перевіряємо сценарії
Відтворення, logs і dependencies.
- 05
Формуємо висновки
Причини, ризики та пріоритети.
- 06
Пропонуємо крок
Виправлення, доопрацювання, міграція або дослідження.
Оцінка
Обсяг залежить від питання та складності проєкту
Локальна проблема може потребувати кілька годин діагностики, великий legacy-проєкт — окремий етап аналізу. Безкоштовний аудит не обіцяємо.
Переглянути ціни →Можливі висновки
Що може змінитися після аудиту
Це приклади результатів, а не кейси конкретних клієнтів.
- замість міграції достатньо доопрацювати модуль
- проблема в cron, а не в CRM
- дублікати виникають через неправильний ID
- checkout конфліктує з custom-кодом
- старий модуль краще замінити
- великий рефакторинг не потрібен
- міграцію потрібно розбити на етапи
- перед новою функцією треба стабілізувати стару логіку
FAQ
Питання та відповіді
Чи потрібен аудит перед кожним доопрацюванням?
Ні. Якщо задача проста й реалізація зрозуміла, окремий аудит не потрібен.
Чи можете перевірити сайт іншого розробника?
Так. Це один із типових сценаріїв.
Чи є це SEO-аудитом?
Ні. Можемо врахувати технічні SEO-ризики під час міграції або змін URL, але це не маркетинговий SEO-аудит.
Чи є це аудитом безпеки?
Не повним. Фіксуємо очевидні ризики, але penetration test і спеціалізований security audit — окремі роботи.
Чи можна після аудиту замовити виправлення?
Так. Висновки можуть стати основою для доопрацювання, нового функціоналу або міграції.
Чи можна оцінити інтеграцію іншого розробника?
Так, якщо доступні код, logs і документація API.
Що отримаємо після аудиту?
Формат залежить від задачі: технічний висновок, пріоритети, рекомендації та наступні кроки.
Чи потрібні доступи одразу?
Для першого обговорення — ні. Після погодження обсягу визначаємо потрібні доступи.
Скільки часу займає аудит?
Локальна діагностика може зайняти кілька годин, а legacy-проєкт — окремий етап аналізу.
Наступний крок
Потрібно зрозуміти, що відбувається всередині проєкту?
Надішліть посилання на сайт і опишіть проблему, заплановану зміну або причину аудиту. Ми визначимо обсяг технічного аналізу.