From Fragile Storefront to Controlled Commerce

1. Project Context

Я підключився до e-commerce-системи, яка вже продавала товари онлайн, але працювала на межі керованості. На сайті одночасно накопичилися технічний борг, дубльована аналітика, складна B2B-логіка, нестабільні фонові задачі та розрив між сайтом, обліком і майбутньою ERP-системою

Моя задача була не просто пришвидшити окрему сторінку, а розібрати весь комерційний контур і підготувати його до контрольованої роботи та подальшої міграції

2. Stage 1 — Audit and Technical Recovery

Почав із read-only аудиту сервера, WordPress, бази даних, плагінів, checkout, оплат, доставки та аналітики. Виявилося, що WordPress мав ліміт пам’яті 40 MB при значно більшому доступному ресурсі сервера, OPcache був переповнений, а таблиці Action Scheduler містили понад 300 000 старих записів і логів

Окремо знайшов кілька паралельних джерел tracking-подій, зайві фонові задачі, старі feed-файли та конфлікти між Code Snippets і кодом теми. Усе це збільшувало навантаження, ускладнювало діагностику та робило комерційні показники ненадійними

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

3. Stage 2 — Commerce Logic, B2B and Checkout

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

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

Окремо виправив проблеми в оплатах і доставці: перевірив міжнародний платіжний сценарій, узгодив поля checkout, зберіг робочі українські способи оплати та привів налаштування доставки до зрозумілої моделі

4. Stage 3 — Stabilization and ERP Readiness

Після виправлення окремих сценаріїв я перевірив повний маршрут замовлення: товар, кошик, checkout, оплату, доставку, повідомлення та оновлення залишків. Додатково налаштував контроль доступів, серверний аудит дій адміністраторів і захист від надмірних автоматизованих запитів

Для майбутнього переходу на ERP я зняв повний snapshot каталогу, варіантів, замовлень і медіатеки, підготував mapping товарів та створив тестовий імпорт. У джерельній системі було зафіксовано 711 батьківських товарів, 3 733 варіації та 103 замовлення

Важливо: на цьому етапі я не видавав підготовку за завершену міграцію. Окремо зафіксував, що ще потребує звірки: склади, залишки, замовлення, платежі, B2B-правила та end-to-end тест перед перемиканням джерела правди

5. Result

За три етапи система перейшла від набору конфліктних налаштувань і непередбачуваних сценаріїв до контрольованого e-commerce-контуру з перевіреною логікою продажу, чистішою аналітикою, зрозумілим B2B-процесом, захищенішою інфраструктурою та підготовленою базою для ERP-міграції

Моя роль охоплювала аудит, технічну діагностику, проєктування процесів, внесення змін, перевірку live-сценаріїв, підготовку доказів і формування наступного плану робіт