Shopify та e-commerce інженер · 5 років в e-commerce, 3 на Shopify
Від оферу та вибору товару до кошика, чекауту, вимірювань і безпечного релізу. Магазини у США, Канаді та Європі. Ви передаєте вітрину й отримуєте готовий результат, у якому відкриті питання вже закриті.
Чому я
Я працюю з усім, що сьогодні справді пришвидшує розробку: відбираю нові інструменти, перевіряю їх на практиці й лишаю тільки те, що витримує бойовий проєкт. Приклад: конвеєр на Figma MCP і Claude Code, який я зібрав вісім місяців тому й відтоді відточую на реальних магазинах. Клієнт отримує не експеримент, а відпрацьований процес.
Проєкт не чекає на дизайнера, менеджера й стороннє рев'ю. Доопрацювання макета, генерація асетів, код, тестування й реліз проходять через одні руки. Коли задача потребує команди, я збираю її і веду сам: такий досвід у мене теж є.
Кожен проєкт я розглядаю як воронку продажів, а не як список задач. Якщо бачу ефективніший спосіб вплинути на конверсію, ніж закладено в ТЗ, пропоную його до початку робіт. Досвід десятків магазинів підказує, які рішення приносять продажі, а які лише створюють видимість активності.
Знаходжу причину, усуваю її, перевіряю й випускаю в продакшн, не зачіпаючи роботу контент-команди. Складнощі лишаються на моєму боці. До вас приходить готовий результат і коротке резюме: що змінилося й на що звернути увагу.
Інструменти на практиці
Нові інструменти потрапляють у мої проєкти лише після того, як довели користь на реальній роботі. Найнаочніший приклад: конвеєр на Figma MCP і Claude Code, який я зібрав вісім місяців тому й відтоді відточую на бойових магазинах. Макет заходить через MCP, Claude Code збирає секцію за патернами самої теми, кожен відступ і радіус звіряються з дизайном. Час, який раніше йшов у розробника на рутинну верстку, тепер іде на інше: на тестування, щоб усе працювало коректно, на пошук недоробок і на більш продумані рішення, зокрема ті, що безпосередньо впливають на швидкість завантаження. Побутова верстка лишилася в минулому, а з нею й епоха нескінченних правок, неправильно зібраних секцій і повільного завантаження, яке в e-commerce б'є і по продажах, і по метриках. Якщо ця епоха десь і триває, то в інших розробників. Фокус змістився на результат: сайт має працювати швидко й без збоїв, і саме на це тепер витрачається вивільнений час.
Де допомагає
Згенерований код іде в продакшн лише після перевірки на кодовій базі, обмеженнях платформи та в чистому середовищі.
Ключовий проєкт
Американський wellness-бренд добавок під NDA. Я заново спроєктував сам підписочний офер: які плани запускати, якій каденції відповідає кожен пак, як показувати ціну, щоб вона завжди збігалася зі списанням, і buy box на нативних Selling Plans без вендорного віджета. Потім вибудував трекінг воронки через закритий чекаут Shopify за допомогою кастомного Web Pixel і знайшов зсув макета, якого PageSpeed не показував. Продажі за вісім тижнів після релізу виявилися на 45% вищими, ніж за вісім тижнів до нього. Абсолютні цифри залишаються в бренду.
Кількість Liquid-файлів у всій темі (Sections, Snippets і Templates), а не секцій на одній сторінці.
Дивитися основний кейс
Підписочний офер, спроєктований і зібраний від і до: плани, каденція під кожен пак, ціна, що завжди збігається зі списанням, без вендорного віджета.
Три непомітні збої кошика, що тихо коштували замовлень, зведені до однієї причини й усунені.
CLS 0.9 у третини мобільних сесій, якого PageSpeed не показував, зведений до нуля.
Вибрані роботи на Shopify
Від складного медичного каталогу до виваженої адаптації преміальної теми: кожен проєкт вимагав іншого балансу власного інтерфейсу, вбудованої поведінки Shopify та контролю з боку продавця.
Absolute Support
Власний шар вибору товару та пояснень для медично складного каталогу, тоді як вбудовані системи Shopify (варіанти, кошик, пошук і фільтрація) лишалися джерелом істини.
Boxwood Coffee
Виважена адаптація Prestige для спеціалізованої обжарки кави: роздріб, підписки, дві кав'ярні, кейтеринг і гурт, де власний код лишили тільки для даних про каву та навігації.
Що беру на себе
З нуля, повні редизайни, кастомні секції та шаблони, metafields на OS 2.0. Піксель у піксель із Figma через MCP-конвеєр.
Recharge, Loop, нативні Selling Plans. Власні віджети підписок, коли вендорне рішення не вписується в дизайн або спотворює ціну. Міграції підписників без подвійних списань. Бандли, паки з живим розрахунком вигоди, апсели, крос-сели, quiz-воронки, product finder, порівняння, будь-який кастомний buy box. Знаю, які з них справді підіймають конверсію, а які лише модні, і кажу про це прямо.
Підписочні сервіси, оптові портали, POS, аналітика, міграції даних без втрат.
Бачу, де клієнт сходить зі шляху до покупки, і усуваю це. Пікселі, події та конверсії по всій воронці, включно з чекаутом: GTM і DataLayer, GA4 ecommerce, Google Ads і Meta Pixel, Amplitude, Klaviyo. Кастомні Web Pixels там, де стандартних недостатньо. Можу взяти цей стек на себе цілком.
Вимірюю на реальних користувачах, а не в PageSpeed. Власні скрипти польових даних показують, яка метрика просідає на якому пристрої, і виправлення спрямоване саме туди. В одному магазині так виявився CLS 0.9 у третини мобільних користувачів, якого лабораторні інструменти не бачили. Зведений до нуля.
Git без втрати контенту й без простоїв. Кілька розробників і контент-команда в Customizer? Вибудовую процес: гілки під теми, ізольовані відкочувані PR, порядок роботи зі спільними файлами. Ніхто не затирає чужу роботу.
Політики, Markets, локалізація, юридичні сторінки. Усе, що потрібно, щоб магазин запустився й не зламався.
Комерційна інженерія
Я працюю глибше за шар теми: описую шлях покупки, знаходжу, де ламається довіра або стан комерції, додаю потрібні вимірювання і змінюю найменшу частину системи, яка може це покращити.
Я простежую шлях від пропозиції до замовлення і знаходжу, де видимий інтерфейс і стан комерції перестають збігатися.
Шлях покупки
Пропозиція
Ціни, набори, знижки
Вибір товару
Варіанти, підписка, пояснення
Кошик
Стан, кількість, drawer
Checkout
Події, доставка, оплата
Замовлення
Підтвердження та подальші кроки
Типові точки збою
Застарілі ціни · Неузгоджені варіанти · Приховані збої кошика · Нестабільність на мобільних · Відсутні події · Прогалини в checkout
Я вирішую, що зробити з вимогою: налаштувати, розширити, інтегрувати чи збудувати.
Налаштувати
Використати платформу там, де вона вже вирішує вимогу.
Розширити
Адаптувати вбудовану систему через презентацію теми та структуровані дані.
Інтегрувати
Під'єднати застосунки та зовнішні системи без дублювання відповідальності.
Збудувати
Додавати власну поведінку лише там, де вимога цього справді потребує.
Мета не в максимальному доопрацюванні, а в найменшому надійному рішенні.
Коли наявної аналітики недостатньо, я додаю інструментацію, щоб спостерігати, діагностувати, змінювати та перевіряти.
Спостерігати
Поведінка та події реальних користувачів
Діагностувати
Знайти першопричину
Змінити
Внести найменше корисне виправлення
Перевірити
Виміряти інженерний результат
Цикл триває, коли з'являються нові дані.
RUM · Checkout Web Pixels · Перевірка в браузері · Операційні перевірки
Кожну зміну перевіряю після релізу на даних самого магазину, а не за лабораторним балом.
Комерційно корисне покращення має також витримати щоденний мерчандайзинг, інтеграції застосунків, оновлення теми та майбутні релізи.
Контроль продавця
Рутинний контент лишається редагованим.
Структуровані дані
Товари й колекції несуть власну інформацію.
Безпечні релізи
Зміни лишаються ізольованими та зворотними.
Сумісність
Власна робота поважає платформу, тему та встановлені застосунки.
Краща вітрина не має ставати магазином, який складніше підтримувати.
Надішліть задачу й мету. Далі розберуся в коді, доведу роботу до релізу й перевірю сам. Англійська B2, із клієнтами зі США працюю напряму, без посередників.
Почати розмову
