Задача і межі, в яких я працювала
Український бренд жіночого одягу в середньому сегменті — те, що називають доступним люксом. Потрібен був не «сайт-вітрина», а магазин, який реально продає й реально обслуговується: з оплатою, накладними, поверненнями і адмінкою, де щодня працюють живі люди.
Команди не було. Розробника поруч теж. Я взяла на себе все — бренд, код і операційну частину, — і закрила проєкт від першого ескізу логотипа до замовлень у продакшені.
- Роль: соло — айдентика, фронтенд, база даних, інтеграції, адмінка, аналітика
- Асортимент: до 1000 товарів, окремий розділ сучасної етніки, лукбуки
- Ринок: Україна, з можливістю міжнародної доставки
- Що НЕ показую: бізнес-цифри клієнтки — виторг, трафік, конверсію. Це не моє, щоб цим світити
Що входило в роботу
Зазвичай це ділять між чотирма: дизайнер, фронтендер, бекендер і той, хто потім усе це супроводжує. Тут усі чотири шапки носила я — тому список нижче не «послуги», а те, що реально стоїть у проді.
Рішення — і чому саме такі
Кожен пункт нижче — це розвилка, де була очевидна легка дорога. Я пішла іншою, і ось чому.
Next.js + Supabase, свій код
Магазин мав уміти те, на чому шаблони спотикаються: оплата частинами тільки від певної суми і тільки для частини брендів, передзамовлення з іншим строком, повний цикл повернень з автоматичним рефандом, імпорт товарів із каналу постачальника. Шаблон довелося б ламати об коліно. Плюс код і дані лишаються в бізнесу, а не в платформи, і комісій платформи немає.
Telegram-бот замовлень
Пошту відкривають раз на день, месенджер — постійно. Нове замовлення падає менеджерам у Telegram миттєво, з усім складом і сумою. Пошта лишилась там, де вона доречна: підтвердження й статуси покупцеві.
Прямий аплоад у хмару з браузера
Серверна дія в Next тримає до 1 МБ, платформа — до 4.5 МБ. Фотографії одягу більші, і на «як завжди» магазин уперся б у ліміт на першому ж лукбуці. Тому файли йдуть у Cloudinary напряму з браузера, повз наш сервер.
Вхід за SMS-кодом
Покупець в Україні живе з телефоном, а не з поштовою скринькою. Вхід — код у SMS (з обмеженням спроб і за номером, і за IP), плюс Google. Один і той самий покупець за телефоном і за поштою склеюється в один профіль, а не роздвоюється.
Атомарне списання залишків у базі
Дві людини о 21:00 тягнуть останню М-ку. Списання зроблено функцією в самій базі, тому останній розмір продається рівно один раз — а не двом покупцям, з яких одному потім телефонують вибачатись.
Цифри
| Метрика | Значення | Що це означає |
|---|---|---|
| Авторів у git | 1 · 278 комітів | Уся кодова база — від однієї людини. Немає «частину робив підрядник» |
| Товарів у каталозі | 192 | Цифра з живого каталогу — її можна перевірити на embody.com.ua/catalog просто зараз |
| Категорій | 17 | Каталог живе й перебудовується під сезон без розробника |
| Доставка × оплата | 9 з 9 | Усі дев'ять комбінацій доходять до оформленого замовлення |
| Успішних оплат | 100% | Картка, оплата частинами і накладений платіж працюють у проді без збоїв |
| UX-проблем знайдено | 23 — закрито всі | Метод GPM-60: 50 синтетичних покупців і 10 прискіпливих критиків проходять магазин ще до релізу. 11 закрила одразу після аудиту, решту — наступними ітераціями |
| Аудити коду й адмінки | 27 · 47 · 24 | Три хвилі перевірок — квітень, травень, червень. Усі знахідки закриті, відкритих не лишилось |
| Час роботи соло | 2 місяці | У середньому по 5 годин на день. Такий самий обсяг для команди оцінюють приблизно в 1350 нормо-годин |
| Відгуків покупців | 15 | Живі, з реальних замовлень — не з генератора |
Дані на 14.07.2026 · джерела: git-історія репозиторію, адмінка EMBODY, звіти аудитів
Як це виглядає
Це не мокапи з дрібла — це знімки живого магазину, який зараз приймає замовлення. Можна відкрити й переклацати самому: embody.com.ua.
Що було складно
Кейс без цього розділу читається як реклама. Тому чесно — три місця, де я витратила більше, ніж планувала.
Пастка, яку не видно очима: підпис платежу
Платіжка не впізнавала мерчанта, хоча код був правильний. Виявилось: у секретний ключ на хостингу заліз невидимий символ переносу рядка — в інтерфейсі значення виглядало ідентичним, а підпис запиту через нього не збігався. Це той клас багів, який не ловиться ні очима, ні код-рев'ю.
Знайшла, виправила й перевірила ще раз — оплата карткою, оплата частинами і накладений платіж працюють у проді без збоїв.
Висновок: секрети тепер заливаю через API і звіряю побайтово, а не покладаюсь на те, що показує інтерфейс хостингу.
Імпортер вигадував артикули
Автоімпорт товарів мав запасний варіант: якщо артикула немає — згенерувати. У результаті 44 товари поїхали в базу з вигаданими артикулами, і склад почав розходитися з реальністю.
Висновок: ніяких «додумати за користувача». Немає артикула в джерелі — товар просто не імпортується, і я про це кажу. Це правило я тепер тягну в кожен проєкт.
Зміни в базі не долітали до сайту
Категорії правилися напряму в базі, а сторінки лишалися старими: кеш фреймворку про правку не знав, нові адреси віддавали 404.
Висновок: будь-яка зміна структури — тільки через шлях, який скидає кеш. Прямий SQL у продакшені — лише з ручним скиданням.
Як перевіряла і як передавала
Магазин, який працює у мене на ноутбуці, нічого не вартий. Далі — що я робила, щоб він працював без мене.
- GPM-60. До релізу магазин проходять 50 синтетичних покупців і 10 критиків з різними характерами й пристроями. Так знайшлося 23 проблеми: 11 закрила одразу після аудиту, решту — наступними ітераціями. Відкритих не лишилось
- Три хвилі аудиту. Квітень — 27 знахідок, травень — 47 по адмінці, червень — регресія на 24 пункти. Кожна хвиля — окремі експерти з окремими ролями. Усе закрито
- Клієнт веде магазин сам. Власниця з менеджером додають товари, обробляють замовлення й повернення, збирають лукбуки. Мене в цьому циклі немає
- Помилку можна відкотити. Журнал дій зі скасуванням протягом 21 дня і кошик для видаленого — щоб випадковий клік не коштував товару
- Рутина автоматична. Накладна створюється сама, гроші за скасоване оплачене замовлення повертаються самі — раніше це були руки менеджера в кабінеті платіжки
Що з цього взяти собі
- Шаблон економить на старті й забирає потім. Щойно у вас з'являється нетипова логіка — розстрочка, передзамовлення, повернення — платформа починає диктувати вам бізнес
- Тестуйте до релізу, а не скаргами покупців. 23 знайдені проблеми — це 23 людини, які не пішли б з кошика
- Адмінка вирішує, чи виживе магазин. Якщо власник не може сам додати товар — він назавжди прив'язаний до розробника, і це його щомісячний рахунок
- Кожна інтеграція — точка відмови. Ключі, підписи, ліміти файлів. Закладайте на це час, інакше «зроблено» і «працює» — різні дати
- Одна людина замість чотирьох — це не про дешевше, а про швидше. Ніхто нікому нічого не передає, і немає тижня на «чекаю макет»
Схожий магазин під ключ — від $2 000, строк 5–8 тижнів. Точну вилку кажу після брифа, у той самий день.
Часті питання
Скільки коштує такий магазин і скільки часу займає?
Магазин на коді під ключ — від $2 000, строк 5–8 тижнів. Ціна залежить від кількості інтеграцій: платіжка, доставка, оплата частинами, повернення, імпорт товарів. Вилку називаю після брифа, у той самий день.
Чи зможу я сам додавати товари, без розробника?
Так. У EMBODY власниця з менеджером ведуть магазин самі: товари, замовлення, повернення, лукбуки, відгуки. До адмін-панелі йде письмовий гайд, а помилкову дію можна скасувати з журналу протягом 21 дня.
Чому не Shopify чи готовий шаблон?
Шаблон швидший на старті, але ламається на нетиповій логіці: оплата частинами від певної суми, передзамовлення з іншим строком, повний флоу повернень з автоматичним рефандом, імпорт товарів із каналу постачальника. У EMBODY це були вимоги, а не побажання. Плюс код і дані належать бізнесу, а не платформі, і комісій платформи немає.
Хто робив дизайн, код і операційну частину?
Одна людина. Логотип, шрифти й айдентика, фронтенд, база даних, інтеграції оплати й доставки, адмін-панель, аналітика — усе соло. У git-історії проєкту один автор і 278 комітів.
Хочете такий самий — напишіть три речення
Що продаєте, на якому ви етапі і що зараз пече найбільше. Цього досить, щоб я сказала, скільки це коштуватиме і за скільки я це зроблю. Відповідаю в той самий день.