Skip to content
LUMA Creative · Bratislava E-commerce and integrations for growing companies +421 907 042 000 peter.kapusnik@lumacreative.online
LUMA Creative
Book a discovery workshop

Our work · Case studies

Case studies. What we built and how it holds up.

Three projects as challenge, solution, result: an e-shop with 44,000+ products under load, a booking system and a catalogue migration. Technical facts only.

01 · Tyre e-shop

PredajPneu.sk

01 Challenge

More than 44,000 tyres from several suppliers. Stock and prices change daily, and the changeover season brings everyone at once. That is exactly when the site cannot slow down.

02 Solution

  • Catalogue fed from the suppliers and the warehouse. Nobody retypes availability.
  • Google Ads and Merchant Center: a product feed of more than 43,000 tyres, a Heureka feed and purchase tracking with order value.
  • TatraPay+ payment gateway: card and bank transfer.
  • An AI assistant that helps pick the right tyre.
  • GDPR-compliant tracking: Consent Mode v2, enhanced conversions and url_passthrough, so a purchase is matched to the ad click even without cookies.
  • Several Next.js nodes behind a load balancer, Redis cache.

03 Result

Load test on 2 Oct 2026 over HTTPS with 500 concurrent connections: about 1,555 requests per second on the catalogue and 1,605 on the product page. Zero errors.

02 · Booking system for a holiday home

TatraGarden Soul

01 Challenge

A mountain cabin below the Tatras that sleeps eight. Guests should book on the site, not through e-mails back and forth. The calendar has to know what is taken, and no human should be working out the price.

02 Solution

  • Next.js 15 and React 19. Slovak and English with translated URLs (/sk/rezervacia, /en/booking).
  • Availability calendar: pending and confirmed bookings, manually blocked dates, the checkout day stays free.
  • The server recalculates the seasonal price, minimum stay and capacity. The browser cannot tamper with it.
  • Two bookings for the same dates get rejected by the server (HTTP 409).
  • The API is guarded by short-lived signed tokens, a honeypot, a minimum fill time and a per-IP rate limit.
  • E-mail goes through Brevo. If the service is down, the booking is still saved.

03 Result

Every image size is generated at startup: 606 of 606 responses come straight from cache. Structured data for lodging, hreflang, a sitemap and llms.txt. The Docker image is about 108 MB and every deploy ends with a health check.

03 · Used-car dealer with a sales system

AUTO BV

01 Challenge

The dealer sells through classifieds and over the phone. Stock changes every week and buyers want to know right away whether the car is still on the lot. The salesman needs to see which enquiry is most likely to close.

02 Solution

  • The catalogue syncs from the classifieds export with one button in the admin: equipment, VIN and every photo.
  • Leads scored by type: viewing, reservation, financing, trade-in, chat. Performance of every listing from view to reservation.
  • An advisor by budget and use, car comparison, a printable vehicle check report and a watchdog that calls back when the wanted car arrives.
  • An hourly job keeps reservations and watchdogs current. If the database is down, the site serves a fallback copy and keeps showing the stock.

03 Result

A website that works like a salesman: it collects enquiries, ranks them and reminds buyers about cars. It runs on Node.js and MongoDB in Docker and shows a maintenance page during deploys.

The numbers in these studies are technical: performance, languages, versions. We never publish our clients' revenue, orders or budgets.

Next step

The fourth study
could be yours.

A 30 to 60 minute discovery workshop. You bring the problem, you leave with a brief and the stages.

Book a discovery workshop Full portfolio