A specialty coffee marketplace for Poland, built end-to-end across mobile, web, and the roastery panel.

5.0

App Store rating, iOS Poland

33+

Specialty roasteries on the platform

400+

Coffees listed across the catalogue

2

Mobile platforms shipped in parallel (iOS + Android)

3

Production servers across two data centres

20+

5★ App Store reviews to date

Kaffy arrived as a brand and a thesis, with the marketplace itself still to build.

The founders had a clear read on the Polish specialty coffee market. Tomasz Weczer had come out of Columbus Coffee and Puro Polska with two decades in HoReCa and FMCG, and Krzysztof Leszczyński had owned brand and IT at Columbus Polska. The product itself was a blank page. The brief was wide: design the buyer experience, design the roastery experience, build them as native apps on both platforms plus the web, ship the back office that runs orders, and stand the whole thing up on infrastructure the business could grow into.

1. A buyer experience that holds up against coffee-shop apps.

   The Polish specialty coffee buyer already lives inside well-designed apps from the leading roasteries and chains. A marketplace that aggregates that audience cannot ship a worse-feeling product than the brands it sits next to.

2. A roastery experience that gets used after the demo.

   Independent roasteries already have their own e-commerce, their own POS, and their own pace. The Kaffy panel had to fit into how they actually run a roastery. Otherwise stock listings go stale inside a month and the listing falls behind reality.

3. Mobile and web in lockstep on day one.

   Aggregating supply only pays off if buyers can find the catalogue everywhere they think to look. iOS, Android, and the web build had to land at the same time, on the same product model, with parity on the parts that matter (search, cart, account, order history) and a single source of truth behind them.

4. Operations infrastructure that the team owns.

   Order management, shipping labels, customer support, and the knowledge base all had to live on Kaffy's stack from day one. The team owns the operational backbone, with no SaaS tools to migrate off later when costs scale.

Discovery before code. A 3–5 year roadmap before the first ticket.

The engagement opened with an intensive product workshop. Kaffy's product strategist, the WAYF product team, and both founders worked through the customer segments, the competitive landscape, the value proposition canvas, and what the win conditions looked like at 12 months and at 3–5 years. The output was concrete: a prioritised feature set for the first build, written KPIs for the 12-month horizon, and a roadmap the rest of the project tracked against.

The discovery work paid back inside the first sprint. The buyer's first-run experience, the roastery panel's permission model, and the way multi-vendor checkout had to behave were all decided in writing before anyone opened a code editor. The design and engineering teams worked from the same brief, and the founders could approve scope at the level it actually shipped at.

A 12-month KPI sheet, signed off by both founders before delivery planning started, became the document every later scope decision pointed back to. New features got measured against the same sheet at every review.

Medusa.js for commerce. React Native for mobile. Next.js for the web. PlanetScale and a three-server multi-DC footprint behind all of it.

The commerce engine is Medusa.js: open, modular, and the right shape for multi-vendor checkout without the lock-in of a hosted platform. Mobile is one React Native codebase compiled to iOS and Android, so the two apps ship at the same time and on the same release cadence. The web build is Next.js, sitting on the same API surface as the apps so feature parity becomes a UI question.

The database is PlanetScale: serverless MySQL with branching, point-in-time recovery, and auto-scaling. Production runs on three dedicated servers across two data centres, so a single-DC failure does not take the marketplace down. Before the apps shipped, the brand lived on a Framer landing page that captured early demand and pre-launch sign-ups without holding back the product build.

• Medusa.js (commerce)
• React Native (iOS + Android)
• Next.js (web)
• PlanetScale (DB)
• 3 servers · 2 data centres
• Framer (pre-launch landing)

Kaffy ID asks four taste questions on the first run and turns the answers into recommendations from the catalogue.

Specialty coffee is a category where taste vocabulary doesn't map onto each buyer the same way. "Fruity" means a Kenyan to one person and a Brazilian natural to another. Kaffy ID is the onboarding that sits between a new user and the 400+ coffees in the catalogue: a short, guided sequence that captures the taste preferences the recommender then uses to surface roasteries and beans that actually fit. The flow is short enough that nobody abandons it, structured enough that the data is useful, and quiet about its own machinery so the buyer just sees "coffees for you" on the home screen.

The catalogue itself is a multi-vendor experience that pretends to be a single store. A buyer browses roasteries side-by-side, adds bags from three different brands into one cart, and pays once. Behind the scenes Kaffy splits the order across roasteries, generates the shipping labels for each, and surfaces a single order history to the buyer. The single-cart pattern matters: it's the difference between a marketplace and a directory.

iOS and Android shipped together on a single React Native codebase, with native treatment where the platforms genuinely diverge.

A coffee marketplace can't credibly ship "iOS first, Android in Q3". Half the audience lives on each side, and brand loyalty in this category is decided in the first week of use. The React Native codebase makes the two apps a single product surface: one product model, one design system, one engineering team. The platform-specific layers (haptics, payment sheets, push, deep links, system share) are written natively when they matter and abstracted when they don't.

The iOS app sits at 5.0 on the Polish App Store as of writing, with 20+ five-star reviews. The score is the read from buyers who use the app week to week, and the read we use internally to decide what's worth shipping next.

A roastery panel sized for the people actually running a roastery, with the surface area trimmed to fit the head roaster's day.

A roastery sells coffee a few hundred bags at a time and has a head roaster who can't spend their day inside a complicated dashboard. The Kaffy panel keeps the surface area tight: products and variants, stock and pricing, order queue, shipping defaults, and an inbox for buyer messages. New listings take a couple of minutes; updates to an existing one take seconds. The panel exposes enough to run the storefront without exposing the moving parts that don't need to be on the head roaster's desk.

Onboarding was done by hand for the first cohort and is being templated as the platform grows. 33+ roasteries are live on the panel today, with the same daily workflow the early-cohort feedback shaped.

Kaffy owns shipping, support, and the knowledge base on the same stack the apps run on.

Shipping labels generate automatically per roastery once an order lands. Customer support sits inside the admin alongside the order it relates to, so a support agent answers a question without alt-tabbing between a ticket tool and the order tool. A knowledge base ships with the marketplace itself, covering coffee origins, processing methods, and flavour profiles. The buyer can read up on what they're about to buy without leaving the app, and support can link to an article instead of writing a paragraph from scratch.

The pattern across the operations layer is consistent: the team that runs Kaffy owns the surface area. Adding a new shipping carrier is a code change against an interface that's already there.

Three production servers across two data centres, with hardening that responds to live operational signal.

Production sits on three dedicated servers across two data centres, so a single-DC failure degrades the marketplace without taking it down. PlanetScale handles the database side with branching for safe migrations and point-in-time recovery so a bad query window stays inside a small blast radius.

Security is an operational discipline that lives with the team running production. After an early incident exposed an abuse pattern the original threat model hadn't priced in, we shipped rate limiting at the application layer, a tighter authentication flow, and a set of monitoring rules that surface the same pattern earlier next time. Treating an incident as signal, and rewriting the relevant slice of the system in response, is the version of security we believe holds up at this scale.