Ein Specialty-Coffee-Marktplatz für Polen, gebaut end-to-end über Mobile, Web und das Rösterei-Panel hinweg.

5,0

App-Store-Bewertung, iOS Polen

33+

Specialty-Röstereien auf der Plattform

400+

Kaffees im gesamten Katalog gelistet

2

Parallel ausgelieferte Mobile-Plattformen (iOS + Android)

3

Produktionsserver über zwei Rechenzentren

20+

Bisherige 5★-App-Store-Bewertungen

Kaffy kam als Marke und These, der Marktplatz selbst war noch zu bauen.

Die Gründer hatten ein klares Gespür für den polnischen Specialty-Coffee-Markt. Tomasz Weczer kam von Columbus Coffee und Puro Polska mit zwei Jahrzehnten in HoReCa und FMCG, und Krzysztof Leszczyński hatte bei Columbus Polska Marke und IT verantwortet. Das Produkt selbst war ein leeres Blatt. Der Auftrag war breit: die Käufer-Erfahrung gestalten, die Rösterei-Erfahrung gestalten, beide als native Apps auf beiden Plattformen plus Web bauen, das Backoffice ausliefern, das die Bestellungen abwickelt, und das Ganze auf einer Infrastruktur aufsetzen, in die das Unternehmen hineinwachsen kann.

1. Eine Käufer-Erfahrung, die gegen die Apps der Coffeeshops besteht.

   Der polnische Specialty-Coffee-Käufer lebt bereits in gut gestalteten Apps der führenden Röstereien und Ketten. Ein Marktplatz, der dieses Publikum bündelt, kann kein Produkt ausliefern, das sich schlechter anfühlt als die Marken, neben denen er steht.

2. Eine Rösterei-Erfahrung, die auch nach der Demo genutzt wird.

   Unabhängige Röstereien haben bereits ihren eigenen E-Commerce, ihr eigenes POS und ihr eigenes Tempo. Das Kaffy-Panel musste sich in die tatsächliche Arbeitsweise einer Rösterei einfügen. Sonst veralten die Bestandsangebote innerhalb eines Monats und das Angebot fällt hinter die Realität zurück.

3. Mobile und Web im Gleichschritt ab Tag eins.

   Angebot zu bündeln zahlt sich nur aus, wenn Käufer den Katalog überall finden, wo sie danach suchen. iOS, Android und der Web-Build mussten gleichzeitig landen, auf demselben Produktmodell, mit Parität bei den Teilen, die zählen (Suche, Warenkorb, Konto, Bestellhistorie), und einer einzigen Source of Truth dahinter.

4. Betriebsinfrastruktur, die dem Team gehört.

   Bestellverwaltung, Versandetiketten, Kundensupport und die Wissensdatenbank mussten alle von Tag eins an auf dem Stack von Kaffy laufen. Das Team besitzt das operative Rückgrat, ohne SaaS-Tools, von denen es sich später lösen müsste, wenn die Kosten mit dem Wachstum steigen.

Discovery vor Code. Eine 3–5-Jahres-Roadmap vor dem ersten Ticket.

Das Engagement begann mit einem intensiven Produkt-Workshop. Kaffys Produktstratege, unser Produktteam und beide Gründer arbeiteten die Kundensegmente, die Wettbewerbslandschaft, das Value Proposition Canvas und die Erfolgskriterien nach 12 Monaten und nach 3–5 Jahren durch. Das Ergebnis war konkret: ein priorisiertes Feature-Set für den ersten Build, schriftlich festgehaltene KPIs für den 12-Monats-Horizont und eine Roadmap, an der sich der Rest des Projekts orientierte.

Die Discovery-Arbeit zahlte sich schon im ersten Sprint aus. Die First-Run-Erfahrung des Käufers, das Berechtigungsmodell des Rösterei-Panels und das erforderliche Verhalten des Multi-Vendor-Checkouts wurden alle schriftlich entschieden, bevor jemand einen Code-Editor öffnete. Design- und Engineering-Teams arbeiteten auf Basis desselben Briefings, und die Gründer konnten den Umfang auf genau der Ebene freigeben, auf der er auch ausgeliefert wurde.

Ein 12-Monats-KPI-Blatt, von beiden Gründern freigegeben, bevor die Lieferplanung begann, wurde zum Dokument, auf das sich jede spätere Umfangsentscheidung berief. Neue Features wurden bei jedem Review am selben Blatt gemessen.

Medusa.js für Commerce. React Native für Mobile. Next.js für Web. PlanetScale und eine Drei-Server-Multi-RZ-Infrastruktur hinter allem.

Die Commerce-Engine ist Medusa.js: offen, modular und in der richtigen Form für Multi-Vendor-Checkout, ohne das Lock-in einer gehosteten Plattform. Mobile ist eine einzige React-Native-Codebasis, kompiliert für iOS und Android, sodass die beiden Apps gleichzeitig und im selben Release-Rhythmus ausgeliefert werden. Der Web-Build ist Next.js und sitzt auf derselben API-Oberfläche wie die Apps, sodass Feature-Parität zur reinen UI-Frage wird.

Die Datenbank ist PlanetScale: serverloses MySQL mit Branching, Point-in-Time-Recovery und Auto-Scaling. Die Produktion läuft auf drei dedizierten Servern über zwei Rechenzentren, sodass der Ausfall eines einzelnen Rechenzentrums den Marktplatz nicht lahmlegt. Vor dem Launch der Apps lebte die Marke auf einer Framer-Landingpage, die frühe Nachfrage und Pre-Launch-Anmeldungen einfing, ohne den Produkt-Build aufzuhalten.

• Medusa.js (Commerce)
• React Native (iOS + Android)
• Next.js (Web)
• PlanetScale (DB)
• 3 Server · 2 Rechenzentren
• Framer (Pre-Launch-Landingpage)

Kaffy ID stellt beim ersten Start vier Geschmacksfragen und macht aus den Antworten Empfehlungen aus dem Katalog.

Specialty Coffee ist eine Kategorie, in der sich das Geschmacksvokabular nicht bei jedem Käufer gleich abbildet. „Fruchtig“ bedeutet für die eine Person einen Kenianer und für die andere einen brasilianischen Natural. Kaffy ID ist das Onboarding zwischen einem neuen Nutzer und den 400+ Kaffees im Katalog: eine kurze, geführte Abfolge, die die Geschmacksvorlieben erfasst, mit denen der Empfehlungsdienst dann Röstereien und Bohnen vorschlägt, die wirklich passen. Der Ablauf ist kurz genug, dass ihn niemand abbricht, strukturiert genug, dass die Daten nützlich sind, und diskret genug über seine eigene Mechanik, sodass der Käufer auf dem Startbildschirm einfach „Kaffees für dich“ sieht.

Der Katalog selbst ist ein Multi-Vendor-Erlebnis, das sich als ein einziger Shop ausgibt. Ein Käufer stöbert Röstereien nebeneinander, legt Tüten von drei verschiedenen Marken in einen Warenkorb und zahlt einmal. Im Hintergrund teilt Kaffy die Bestellung auf die Röstereien auf, erzeugt für jede die Versandetiketten und zeigt dem Käufer eine einzige Bestellhistorie. Das Ein-Warenkorb-Prinzip ist entscheidend: Es ist der Unterschied zwischen einem Marktplatz und einem Verzeichnis.

iOS und Android gemeinsam ausgeliefert auf einer einzigen React-Native-Codebasis, mit nativer Umsetzung dort, wo die Plattformen wirklich auseinandergehen.

Ein Kaffee-Marktplatz kann nicht glaubwürdig „iOS zuerst, Android in Q3“ ausliefern. Die Hälfte des Publikums lebt auf jeder Seite, und Markentreue entscheidet sich in dieser Kategorie in der ersten Nutzungswoche. Die React-Native-Codebasis macht die beiden Apps zu einer einzigen Produktoberfläche: ein Produktmodell, ein Designsystem, ein Engineering-Team. Die plattformspezifischen Schichten (Haptik, Payment-Sheets, Push, Deep Links, System-Share) werden nativ geschrieben, wo es darauf ankommt, und abstrahiert, wo nicht.

Die iOS-App steht zum Zeitpunkt des Schreibens bei 5,0 im polnischen App Store, mit 20+ Fünf-Sterne-Bewertungen. Der Wert ist das Urteil der Käufer, die die App Woche für Woche nutzen, und das Urteil, anhand dessen wir intern entscheiden, was sich als Nächstes zu bauen lohnt.

Ein Rösterei-Panel, zugeschnitten auf die Menschen, die eine Rösterei tatsächlich betreiben, mit einem Funktionsumfang, der auf den Alltag des Chefrösters zugeschnitten ist.

Eine Rösterei verkauft Kaffee in Chargen von ein paar Hundert Tüten und hat einen Chefröster, der seinen Tag nicht in einem komplizierten Dashboard verbringen kann. Das Kaffy-Panel hält den Funktionsumfang schlank: Produkte und Varianten, Bestand und Preise, Bestell-Queue, Versandvorgaben und ein Postfach für Käufernachrichten. Neue Angebote brauchen ein paar Minuten; Aktualisierungen an einem bestehenden dauern Sekunden. Das Panel zeigt genug, um die Storefront zu betreiben, ohne die beweglichen Teile offenzulegen, die nicht auf dem Schreibtisch des Chefrösters liegen müssen.

Das Onboarding wurde für die erste Kohorte von Hand gemacht und wird mit dem Wachstum der Plattform in Vorlagen überführt. 33+ Röstereien sind heute auf dem Panel aktiv, mit demselben täglichen Workflow, den das Feedback der frühen Kohorte geprägt hat.

Versand, Support und Wissensdatenbank gehören Kaffy auf demselben Stack, auf dem die Apps laufen.

Versandetiketten werden pro Rösterei automatisch erzeugt, sobald eine Bestellung eingeht. Der Kundensupport sitzt im Admin direkt neben der zugehörigen Bestellung, sodass ein Support-Mitarbeiter eine Frage beantwortet, ohne zwischen einem Ticket-Tool und dem Bestell-Tool hin- und herzuwechseln. Eine Wissensdatenbank kommt mit dem Marktplatz selbst und deckt Kaffee-Herkünfte, Aufbereitungsmethoden und Geschmacksprofile ab. Der Käufer kann sich über das informieren, was er kaufen möchte, ohne die App zu verlassen, und der Support kann auf einen Artikel verlinken, statt einen Absatz von Grund auf zu schreiben.

Das Muster über die gesamte Betriebsschicht hinweg ist konsistent: Das Team, das Kaffy betreibt, besitzt den Funktionsumfang. Einen neuen Versanddienstleister hinzuzufügen ist eine Codeänderung gegen eine Schnittstelle, die bereits vorhanden ist.

Drei Produktionsserver über zwei Rechenzentren, mit Härtung, die auf reale Betriebssignale reagiert.

Die Produktion sitzt auf drei dedizierten Servern über zwei Rechenzentren, sodass der Ausfall eines einzelnen Rechenzentrums den Marktplatz beeinträchtigt, ohne ihn lahmzulegen. PlanetScale übernimmt die Datenbankseite mit Branching für sichere Migrationen und Point-in-Time-Recovery, sodass ein fehlerhaftes Query-Fenster in einem kleinen Wirkungsradius bleibt.

Sicherheit ist eine operative Disziplin, die beim Team liegt, das die Produktion betreibt. Nachdem ein früher Vorfall ein Missbrauchsmuster offengelegt hatte, das das ursprüngliche Bedrohungsmodell nicht eingepreist hatte, haben wir Rate Limiting auf Anwendungsebene, einen strengeren Authentifizierungsablauf und eine Reihe von Monitoring-Regeln ausgeliefert, die dasselbe Muster beim nächsten Mal früher sichtbar machen. Einen Vorfall als Signal zu behandeln und den betroffenen Teil des Systems daraufhin neu zu schreiben, ist die Version von Sicherheit, von der wir glauben, dass sie in dieser Größenordnung Bestand hat.