Dokumentation

wein-online-verkaufen.de — Dokumentation

Wie die Plattform aufgebaut ist, was sie kann und wie Sie damit arbeiten. Geschrieben für zwei Gruppen: Winzerinnen und Winzer, die ihren Shop pflegen — und alle, die die Plattform betreiben oder erweitern.

Einstieg

wein-online-verkaufen.de ist keine Shop-Software, die Sie installieren, sondern eine betriebene Plattform: Jedes Weingut bekommt seinen eigenen Shop unter eigener Adresse, mit eigenem Logo und eigenem Stripe-Konto. Geteilt werden nur die Dinge, die niemand zweimal braucht — Commerce-Backend, Datenbank, Medienspeicher, Zertifikate und Betrieb.

Der Weg dorthin läuft in Selbstbedienung: E-Mail-Adresse eintragen, im Cockpit einen Tarif buchen — wenige Minuten später ist der Shop unter ihr-weingut.wein-online-verkaufen.de online. Für Sie als Winzer heißt das: Sie pflegen Ihre Weine und Ihre Geschichte, um alles andere kümmern wir uns. Für Technikerinnen und Techniker heißt es: eine Multi-Mandanten-Architektur auf Medusa v2 und SvelteKit, sauber getrennt über Sales Channels, deployt über Docker und Traefik — mit einer Provisioning-Pipeline, die neue Shops ohne Handarbeit anlegt.

Lesepfade

Je nachdem, warum Sie hier sind, lohnen sich unterschiedliche Reihenfolgen.

Ich bin Winzerin oder Winzer

  1. Onboarding — vom Registrieren bis zum eigenen Shop
  2. Quick-Start — die ersten fünf Handgriffe
  3. Feature-Katalog — was der Shop alles kann
  4. FAQ — Freischaltung, Kosten, Domain, Stripe

Ich betreibe oder erweitere

  1. Systemarchitektur — der Aufbau im Ganzen
  2. Komponenten — jeder Baustein einzeln
  3. Deployment — Build, Push, Smoke-Test
  4. Onboarding — Provisioning-Pipeline und Status

Alle Kapitel

Konventionen

Vier Sorten farbiger Hinweisboxen begleiten den Text. Sie sehen so aus:

Statusangaben

Im Feature-Katalog steht hinter jedem Punkt ein Status: Live heißt, das Feature läuft im Produktivbetrieb bei mindestens einem Weingut. In Arbeit heißt, es ist begonnen oder geplant, aber noch nicht ausgerollt. Wir schreiben nichts als „live“, was wir nicht selbst im Betrieb gesehen haben.

Jeder API-Fehler muss dem Nutzer sichtbar sein — nie leere Boxen oder leere Flächen. Immer Fehler- und Ladezustand vorsehen.
Lessons Learned · internes Entwicklungsprotokoll, Gutschein-Release

Dieser Satz steht seit dem Gutschein-Release in unseren Entwicklungsnotizen und erklärt ganz gut, wonach die Plattform gebaut ist: Lieber eine ehrliche Meldung als eine hübsche, leere Oberfläche.