Case study · my own store

2,027 orders in one month. Zero manual fulfillment.

KAMAR is a Polish toy store I co-founded and run the engineering for. It is not a client project — it runs on my own money, against real customers and real ad spend, every day. That makes it the most honest case study I can show you: nobody paid me to say any of this worked.

orders in December 2025: 2,027 orders in December 2025
orders per day, in season: 25–50 orders per day, in season
visits per month: 150K+ visits per month
add-to-cart after my rewrite: 2.5s → 0.5s add-to-cart after my rewrite
supplier orders typed by a human: 0 supplier orders typed by a human
ROAS on paid acquisition: 9+ ROAS on paid acquisition

The problem

A store that grows is a store that drowns you in repetition

At 25–50 orders a day, three things were quietly killing the business: every order had to be re-typed by hand into a supplier website with no API; the shared hosting buckled under seasonal traffic; and an add-to-cart that took ~2.5 seconds was bleeding mobile conversions we were paying real ad money to win.

These are the same three problems I now see in almost every store I look at — fulfillment that eats hours, infrastructure at its ceiling, and a slow buying path. The difference is that on my own store I had to actually solve them, or pay for them every single day.

What I built

Four systems that run the store so humans don't have to

The fulfillment bot

The store is dropshipping, and the supplier offers no API — every production order used to mean a human logging into their website and re-typing it. I built a headless-browser bot that drives the supplier’s site directly: it logs in, fills the order form, places the order and records the result. It runs unattended for 25–50 orders a day, with a Firebase-backed admin panel and alerts for the rare case that needs a human. Fulfillment labor: effectively zero.

Headless browser
Firebase
Admin panel
Alerting

The performance rewrite

Add-to-cart took ~2.5 seconds — an eternity when a parent is buying a birthday present on a phone. I wrote custom WordPress mu-plugins that rebuilt the hot paths and cut it to under 0.5 seconds, alongside the caching and database tuning that keeps Core Web Vitals green on a catalog with thousands of products.

mu-plugins
Core Web Vitals
Redis
OPcache

The infrastructure migration

The store started on SiteGround shared hosting and was choking under real traffic. I migrated it to a Hetzner CX53 VPS on OpenLiteSpeed with Redis and OPcache — including server hardening, a staging environment with sync scripts, automated backups and one-command deploys. Faster pages, full control, lower cost per visit.

Hetzner VPS
OpenLiteSpeed
Hardening
Staging + deploys

The operations layer

Everything else that quietly runs the business: cron jobs for stock sync and supplier feeds, email workflows, a Cloudflare Worker on the edge, and the SEO plumbing. The store operates day to day without me sitting in the admin.

Cron jobs
Stock sync
Cloudflare Workers
Email workflows

Why this matters to you

I've already made these mistakes on my own money

When you hire a developer, you're usually paying them to learn e-commerce on your store. I run one. I know what a failed payment costs on a Saturday night, what a 2.5-second add-to-cart does to a mobile funnel, and how many hours a week manual fulfillment really burns — because it was my money, my weekend, and my hours.

If your store has one of the problems above — fulfillment or back-office work that only exists because "there's no API", a slow buying path, or hosting you've outgrown — I've solved it before, in production, for years, on a store that couldn't afford for the fix to fail.

Tell me about your store See fixed-price services

Back to marc-stan.com