Як за місяць я створив ZbirkaPrice: простий SaaS для моніторингу цін

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт! Мене звати Максим, моя професійна кар’єра тривалий час була пов’язана з UX/UI та продуктовим дизайном, але останній рік я вирішив повністю зосередитись на створенні власних застосунків: спочатку на Swift (iOS, MacOS), потім переключився на Java Script, на якому зробив чотири застосунки для Jira. В принципі, на цьому варто було зупинитись і зосередитись на їх маркетингу та просуванні, що я і робив, поки не зустрів свого знайомого...

Ідея

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

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

Зробивши дослідження, я звичайно знайшов декілька рішень на ринку для моніторингу цін, але одні були занадто перевантажені функціоналом (як і ціною за користування), а інші — те саме, але ще й заточені виключно під Amazon (Keppa).

Тож трохи подумав, чи готовий я зануритись в цю нову подорож, накидав функціонал, який я хочу бачити (і яким користуватись) у майбутньому сервісі, відкрив Visual Studio Code і понеслося... хоча стоп! Я ж у минулому — дизайнер!

Розробка

Як і будь-який поважаючий себе дизайнер, я вирішив, що будь-що в житті треба починати з чого — правильно, з логотипу! З якого я і почав. Оскільки одразу знав, що хочу отримати на виході, відкрив Figma і досить швидко зробив логотип, визначився з кольорами для світлої й темної теми, кнопками тощо.

Але «квітково-букетний» період не може продовжуватись занадто довго. Для мене це означало закрити Figma і відкрити Visual Studio Code. Досвід розробки під Java Script, як я писав, у мене був. Але нюанс у тому, що до цього моменту я робив застосунки для готових платформ, які мають власні маркетплейси та вбудовані зручні платіжні системи. А у випадку Atlassian вона ще має Jira Cloud інфраструктуру платформи (сервери, оновлення та базу даних самої Jira). Тож розгортати та адмініструвати самостійно не потрібно, ці питання закривала сама Jira.

А мене очікувала робота з базою даних, її налаштуванням, правильним підключенням платіжної системи, яка після оплати відкривала б потрібні функції платформи з прив’язкою до користувача. Занурившись у ці питання, Google та ChatGPT, я обрав наступний стек:

Node.js + Prisma + PostgreSQL для бекенду. Playwright/Chromium для парсингу сторінок та отримання даних із сайтів. Усе працює на Railway — і сервіс, і база даних.

Щодо бази даних, схема наступна: є таблиця товарів (з посиланням, назвою, зображенням і валютою) та таблиця знімків цін (зі значенням і часовою міткою для їх фіксації в часі). Ціни зберігаю у форматі NUMERIC(12,2), попередньо очищаючи їх від зайвих символів. Є індекси для швидкого пошуку, а унікальність пари (product_id, scraped_at) не дозволяє плодити дублікати.

На фронті користувач отримує наступний функціонал:

• додаєш посилання на товар (eBay, Olx, маркетплейси, магазини тощо) — сервіс автоматично підтягне назву, посилання, опис товару, фото, поточну ціну та валюту;
• групуєш позиції у категорії, щоб зручно розкладати за ними товар;
• задаєш свою ціну для порівняння та валюту (за замовчуванням вона відповідає валюті в доданому товарі);
• натискаєш Refresh, сервіс знову забирає актуальну ціну з джерел на момент оновлення;
• фільтруєш товари за зміною ціни, «знизилась» або «підвищилась», щоб одразу бачити лише позиції з актуальною зміною;
• інтерфейс підтримує кілька мов (українська, англійська, польська, чеська, естонська) та популярні валюти.

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

Проблеми, які багато чому навчили

Запускаючи сервіс, я відразу зіткнувся з низкою технічних викликів. Ось основні з них:

1. Навантаження на базу даних

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

Рішення: я виніс оновлення цін у чергу задач й обробляю їх воркерами з контрольованою паралельністю, увімкнув PgBouncer та зменшив пул з’єднань у Prisma. Додав rate limiting і ідемпотентність (1 продукт = 1 активна задача), тож пікові запити дозуються, дублікати відсікаються, а база працює стабільно без тайм-аутів і збоїв.

2. Робота з різними форматами даних та складнощі з отриманням цін

Проблема: сайти використовують дуже різні формати цін (10 000, 10.000, 10,00 €, €10), а деякі спеціально захищаються від парсингу.

Рішення: я створив систему, яка:

1. Розпізнає й нормалізує різні формати цін.
2. Поважає захищені сайти та не намагається їх обходити.
3. Працює лише з доступними джерелами.

Деталі:

1. Аналізуються лише сайти без заборон у robots.txt.
2. Не використовуються методи обходу захисту.
3. При значних труднощах з парсингом такі сайти виключаються.

Чому саме так: етичний підхід дозволяє сервісу залишатися стабільним і законним, не порушуючи правил використання джерел даних.
ㅤ
3. Запуск браузера в контейнері

Проблема: під час першого розгортання сервіс не запустився, оскільки в образі Docker не вистачало необхідних бібліотек для роботи Chrome.

Рішення: я додав потрібні системні пакети, оптимізував Docker-образ для зменшення розміру, обмежив кількість одночасних перевірок цін і реалізував систему повторних спроб із чеканням завантаження елементів на сторінках.
ㅤ
4. Розбіжності в налаштуваннях

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

Рішення: я переніс усі критичні параметри в центральне сховище Railway, чітко розділивши змінні для етапу збірки та етапу виконання. Додатково додав перевірку наявності всіх необхідних налаштувань під час запуску програми.
ㅤ
5. Затримки під час запуску сервісу

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

Рішення: я налаштував постійні HTTP-з’єднання, додав ендпоїнти для перевірки стану сервісу, оптимізував налаштування таймаутів для бази даних і реалізував кешування DNS-запитів для прискорення роботи.

Як я стежу, щоб усе працювало

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

Що я НЕ робив у першій версії

Я спеціально не намагався зробити все і відразу. Головне зараз — це щоб парсинг цін працював надійно, а порівняння цін було зручним. Решту ідей я зберігаю на майбутнє. Так я швидше отримую зворотний зв’язок і роблю те, що людям дійсно потрібно.

Що я зрозумів під час розробки

• Стабільність важливіша за пікову швидкість: краще мати невеликий, але стійкий пул з’єднань і спокійний продакшн, ніж «швидкість», яка валиться під навантаженням.
• Швидкий інтерфейс + важкі задачі у фоні: користувацькі дії мають відпрацьовувати миттєво, а все ресурсомістке виконуватися окремими процесами/воркерами.
• Перевірка налаштувань наперед: конфіг (ENV, ключі, ліміти) варто валідувати на старті, менше сюрпризів під час деплою.
• Акуратність із числами та валютами: нормалізація без компромісів, основа коректних рішень і чистих даних.
• Ітеративний підхід: маленькі кроки й часті невеликі релізи ефективніші за великі «перебудови».

Що далі

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

Спробувати безкоштовно можна тут: zbirkaprice.com

Подивитись демо: Youtube

Написати особисто: [email protected]