E‑Commerce‑MVP in 7 Tagen: ein Tag‑für‑Tag‑Plan, um einen kleinen Shop mit Katalog, Checkout, echten Zahlungen, einfachem Admin und sicheren Releases zu veröffentlichen.
Für ein E‑Commerce‑MVP, das du in einer Woche abschließen willst, bedeutet „echte Zahlungen“ eine Sache: ein echter Kunde kann zahlen, du siehst die Bestellung, und du kannst sie versenden, ohne zu raten.
Halte die erste Version eng: ein Land, eine Währung und eine Zahlungsart (meist Karten). Wenn du versuchst, alles zu unterstützen, verbringst du die Woche mit Randfällen statt mit Verkaufen.
Der kürzeste Weg ist ein winziger Shop, der nur die Schritte erledigt, die nötig sind, um Geld zu bewegen und die Erfüllung auszulösen:
„Fertig“ ist kein perfektes Schaufenster. „Fertig“ heißt: eine Bestellung annehmen, erfolgreich belasten und dieselben Tag erfüllen mit den gesammelten Daten. Wenn du das für 10 Bestellungen hintereinander ohne manuelle Korrekturen schaffst, hast du ein funktionierendes MVP.
Um dieses Ziel zu schützen, entscheide im Voraus, was außerhalb des Scopes liegt. Diese Funktionen wirken zwar standardmäßig, sind aber nicht nötig, um diese Woche bezahlt zu werden: Wunschlisten, Bewertungen, erweiterte Suche, komplexe Inventarregeln, Gutscheine, mehrere Zahlungsmethoden und mehrere Währungen.
Wähle zuerst ein Zielgerät. Wenn die meisten Käufer über Social Ads kommen, mobile‑first Web. Wenn du an Unternehmen verkaufst, ist Desktop‑first in Ordnung. Entwirf in jedem Fall zuerst für eine Bildschirmgröße und passe später an.
Wenn du mit einem chatbasierten Tool wie Koder.ai baust, schreibe den Scope auf, bevor du Screens und Flows generierst. Ein strikter Scope ist der einfachste Weg, um „nur noch ein Feature" davon abzuhalten, in Tag 8 zu enden.
Ein E‑Commerce‑MVP ist „echt“, wenn ein Fremder ein Produkt finden, zahlen und du die Bestellung ohne Hin‑ und Her‑E‑Mails erfüllen kannst.
Beginne mit Produkten. Du brauchst einen Titel, einen Preis, ein Hauptbild, eine kurze Beschreibung und einen An/Aus‑Schalter, damit du Artikel verbergen kannst, ohne sie zu löschen. Varianten, Bundles und komplexe Preisgestaltung kommen später.
Dein Katalog kann einfach bleiben: eine Produktlisten‑Seite und eine Produktdetailseite. Basisfilter (z. B. Kategorie oder vorrätig) sind ok, baue aber in Woche eins keine komplette Suchmaschine.
Warenkorb und Checkout sollten langweilig und vorhersehbar sein. Der Warenkorb muss hinzufügen, entfernen, Menge ändern und eine klare Zwischensumme anzeigen. Für Versand und Steuern wähle zuerst eine einfache Regel (z. B. Pauschalversand und Steuer nur wenn nötig).
Ein minimaler End‑to‑End‑Flow braucht üblicherweise:
Admin ist ein häufiger Grund, warum MVPs scheitern. Du brauchst keine Charts. Du brauchst einen geschützten Login, eine Möglichkeit, Produkte hinzuzufügen/zu bearbeiten, und eine Bestellliste, in der du den Status ändern kannst (new, paid, shipped, refunded).
Beispiel: Du verkaufst drei Kerzen. Jede hat ein Foto und einen Preis. Ein Käufer legt zwei in den Warenkorb, sieht 5 $ Pauschalversand, gibt seine Adresse ein, zahlt, dann markierst du die Bestellung als versandt, nachdem du das Label ausgedruckt hast.
Wenn du eine vibe‑coding Plattform wie Koder.ai nutzt, halte das Prompt strikt: „Nur diese Seiten, nur diese Felder, keine Accounts, keine Gutscheine, keine Wunschlisten."
Bei Zahlungen ist Kreativität zu vermeiden. Wähle einen Provider, mit dem du dich schnell anmelden kannst, und biete zunächst nur Kartenzahlungen an. Digitale Wallets, BNPL und Überweisungen können später kommen.
Die größte Entscheidung ist der Zahlungsfluss:
Behandle Zahlungen als eine kleine Menge von Zuständen, die du auf einen Blick verstehen kannst: created, paid, failed, canceled, refunded.
Speichere nur, was du für Abgleich und Support brauchst: die Provider‑Payment‑ID, optional Provider‑Customer/Session‑ID, Betrag, Währung und deine interne Order‑ID. Rohdaten der Karte niemals speichern und erfinde keine eigenen Zahlungsfelder, es sei denn, du brauchst sie wirklich.
Webhooks machen Bestellungen zuverlässig. Nach dem Checkout gehe nicht davon aus, dass ein Browser‑Redirect „paid“ bedeutet. Füge einen Webhook‑Handler hinzu, der das Event verifiziert und dann die passende Bestellung als bezahlt markiert.
Sorge dafür, dass dein System bei Wiederholungen sicher ist. Webhooks werden öfter als einmal zugestellt, also sollte dein Handler idempotent sein: Wenn eine Bestellung bereits bezahlt ist, soll er nichts tun und dennoch Erfolg zurückgeben.
Wenn du schnell mit einem chatgesteuerten Builder wie Koder.ai baust, definiere zuerst Zahlungszustände und minimale Felder, dann generiere den Webhook‑Endpunkt und die Logik zur Bestellaktualisierung. Diese Klarheit verhindert das klassische Chaos: bezahlte Kunden, unbezahlte Bestellungen und Stunden manueller Überprüfung.
Tag 1: Scope festlegen. Schreibe ein einseitiges Spec: was ein Käufer tun kann, was ein Admin tun kann und was außerhalb des Scopes liegt. Wähle einen Zahlungsanbieter. Entscheide, wie du Summen berechnest (Steuern/Versand jetzt oder später). Skizziere fünf Schlüsselbildschirme: Katalog, Produktseite, Warenkorb, Checkout, Zahlungsergebnis.
Tag 2: Katalog veröffentlichen. Speichere Produkte nur mit den Feldern, die du brauchst: Name, Preis, Währung, Foto, kurze Beschreibung, Aktiv‑Flag. Baue eine „Alle Produkte“‑Seite (oder einfache Kategorien) und eine Produktdetailseite. Befülle etwa 10 Testprodukte, damit du echte Flows testen kannst.
Tag 3: Warenkorb und Bestellentwürfe. Implementiere hinzufügen/entfernen und Mengenänderung. Wenn der Checkout beginnt, erstelle einen Bestellentwurf und snapshotte Preise, damit spätere Produktänderungen alte Bestellungen nicht ändern. Erfasse E‑Mail und Versandadresse früh.
Tag 4: Zahlungen im Testmodus. Verbinde den Checkout mit der Zahlungsanlegung. Handle Erfolg, Abbruch und Fehler. Speichere den Zahlungsstatus auf der Bestellung. Zeige eine klare Bestätigungsseite mit Bestellnummer und nächsten Schritten.
Tag 5: Grundlegendes Admin für Erfüllung. Halte das Admin klein: Produkt erstellen/bearbeiten/deaktivieren, eine Bestellliste mit Statusupdates (paid, packed, shipped, refunded) und eine einfache „Bestellung ansehen“‑Seite mit allem, was du zum Versenden brauchst.
Tag 6: Deployment und Sicherheit. Richte separate Staging‑ und Production‑Umgebungen ein, aktiviere Logs und probe den gesamten Flow mit Testkarten. Schreibe einen Rollback‑Plan, bevor du ihn brauchst.
Tag 7: Live gehen (klein, kontrolliert). Führe einen finalen Durchlauf mit einem echten, kleinen Kauf durch, bestätige E‑Mails/Quittungen und öffne den Shop zuerst für ein kleines Publikum. Wenn du Koder.ai nutzt, mache vor jeder größeren Änderung einen Snapshot, damit du bei Checkout‑Fehlern schnell zurück kannst.
Ein Woche‑E‑Shop lebt oder stirbt an Klarheit bei Bestellungen. Sobald jemand bezahlt, solltest du schnell beantworten können: Was hat er gekauft, wohin wird es versandt und wie ist der aktuelle Status?
Beginne mit einem kleinen, langweiligen Datenmodell. Diese fünf Records decken fast alles ab:
Halte Adressen minimal, damit der Checkout schnell bleibt. In der Regel reichen Name, Linie1, Stadt, Postleitzahl und Land. Telefon kann optional sein, außer dein Carrier verlangt es.
Speichere Summen als Snapshot zum Kaufzeitpunkt. Ziehe später keine Beträge aus der Product‑Tabelle neu. Preise ändern sich, Versandtarife werden angepasst und du stehst sonst vor „Der Kunde zahlte X, aber die Bestellung sagt jetzt Y“. Speichere Stückpreis pro Artikel sowie Bestell‑Zwischensumme, Versand, Steuer (auch wenn 0) und Gesamt.
Verwende klare Status, die zur Erfüllung passen und nicht zu viel Provider‑Jargon enthalten: new, paid, packed, shipped, canceled. Füge refunded nur hinzu, wenn du es wirklich unterstützt.
Plane Idempotenz bei Zahlungsupdates. Dasselbe Webhook‑Event kann zweimal oder in falscher Reihenfolge ankommen. Speichere eine eindeutige Event‑ID des Providers und ignoriere Duplikate.
Beispiel: Ein Webhook markiert eine Zahlung zweimal als „succeeded“. Dein System sollte nicht zwei Sendungen erstellen oder zwei Bestätigungs‑E‑Mails verschicken. Wenn du Koder.ai mit einem Go‑Backend und PostgreSQL verwendest, reicht oft eine Unique‑Constraint auf (provider, raw_event_id) plus eine Transaktion um das Status‑Update.
Admin ist kein „Dashboard“. Es ist ein kleiner Backroom, in dem du drei Fragen schnell beantwortest: Was ist im Verkauf, was wurde bezahlt, und was muss versandt werden.
Starte mit einem einzigen Admin‑Login. Eine Rolle reicht. Nutze ein starkes Passwort, einfache Rate‑Limiting‑Regeln und eine kurze Session‑Timeout. Überspringe Personalverwaltung und Berechtigungen in dieser Woche. Wenn du eine zweite Person brauchst, teile den Zugang bewusst und rotiere das Passwort später.
Halte Produktverwaltung simpel: erstellen/bearbeiten, ein Hauptbild hochladen, Preis setzen, Verfügbarkeit umschalten. Baue Inventarzähle nur, wenn du sie wirklich hast. Ein In‑Stock/Out‑Of‑Stock‑Schalter verhindert meist Überverkäufe.
Deine Bestellansicht sollte wie ein Packzettel lesbar sein. Einfaches Suchen nach Bestell‑ID oder Kunden‑E‑Mail, und dann anzeigen:
Für Statusaktionen behalte zwei Buttons: „Mark packed“ und „Mark shipped“. Beim Markieren als versandt kannst du optional eine Tracking‑Notiz speichern (Carrier + Tracking‑Code oder „Lokale Abholung vereinbart"). Automatisierte E‑Mails können warten, wenn sie dich ausbremsen.
CSV‑Export ist optional. Füge ihn nur hinzu, wenn du weißt, dass du ihn in Woche eins brauchst.
Wenn du ein Build‑Tool wie Koder.ai nutzt, halte das Admin in derselben App, aber schütze die Route und require eine gültige Session.
Starte im Testmodus. Dein Ziel ist nicht „eine Checkout‑Seite“. Dein Ziel ist eine Bestellung, die bezahlt, erfasst und versandbereit ist.
Regel: Speichere niemals rohe Kartendaten auf deinem Server. Nutze Hosted Checkout oder clientseitige Tokenisierung, sodass sensible Daten direkt zum Payment‑Provider gehen.
Logge Zahlungsfehler mit Kontext, den du verwenden kannst: Bestell‑ID, Session‑ID, Kunden‑E‑Mail (falls vorhanden), erwartete Summe, Provider‑Fehlercode und eine kurze Nachricht wie „Amount mismatch" oder „Webhook signature invalid".
Beispiel: Ein Kunde versucht, zwei Tassen zu kaufen. Dein Server berechnet 24 $ + Versand, erstellt die Session und zeichnet eine Bestellung als pending auf. Schließt der Kunde die Seite, wird die Bestellung canceled. Zahlt er, flippt der Webhook sie zu paid und du kannst sie sicher erfüllen.
Wenn du nur eine Woche hast, werden Deployments leicht zur Ursache, die den Checkout kaputt macht. Das Ziel ist kein fancy DevOps, sondern eine wiederholbare Routine, die Überraschungen reduziert und dir ein Fluchttor gibt.
Richte zwei Umgebungen ein: staging und production. Staging sollte so nah wie möglich an Production sein: gleiche Settings, gleiche Templates, gleiche Steuer/Versand‑Regeln, aber Zahlungen im Testmodus. Führe finale Checks in Staging aus und promote dann genau dasselbe Build nach Production.
Nutze versionierte Releases. Auch wenn es nur v1, v2, v3 ist, tagge jedes Release und halte das vorherige bereit. Rollback sollte eine Aktion sein: zurück zum vorherigen Build wechseln oder einen Snapshot wiederherstellen. Wenn deine Plattform Snapshots und Rollback unterstützt (Koder.ai tut das), mache es dir zur Gewohnheit, vor jedem Production‑Release ein Snapshot zu erstellen.
Behandle Datenbankmigrationen in der MVP‑Woche als riskant. Bevorzuge rückwärtskompatible Änderungen: neue Tabellen/Spalten hinzufügen, nicht umbenennen oder löschen, und halte alte Codepfade solange aktiv, bis das neue Release stabil ist. Wenn du Daten nachträglich füllen musst, mache das in einem separaten Job, nicht innerhalb einer Request.
Halte Secrets aus dem Repo. Nutze Umgebungsvariablen oder einen Secret‑Manager für API‑Keys, Webhook‑Signing‑Secrets, Datenbank‑URLs und Admin‑Passwörter.
Release‑Checklist:
Der schnellste Weg, das 7‑Tage‑Ziel zu verfehlen, ist, „schöne“ Features zu bauen, die stillschweigend den Geldfluss kaputtmachen. Der Punkt ist ein Shop, der Zahlung entgegennimmt, eine verlässliche Bestellung erstellt und dir die Erfüllung ermöglicht.
Ein häufiger Fehler ist, dem Browser die finale Preisentscheidung zu überlassen. Wenn Summen, Rabatte oder Versand im Client berechnet werden, wird irgendwann jemand den falschen Betrag zahlen. Mach den Server zur einzigen Quelle der Wahrheit: Baue die Bestellung aus Produkt‑IDs und Mengen neu auf und berechne Summen erneut, bevor du eine Zahlung erstellst.
Versand‑ und Steuerregeln sind ein weiterer Zeitfresser. Teams verlieren Tage damit, jedes Land und jeden Randfall zu unterstützen. Für Woche eins wähle eine einfache Regel und bleibe dabei.
Zahlungen können im Checkout zwar „funktionieren“, aber in der Operations‑Praxis scheitern, wenn Webhooks fehlen. Ein Kunde zahlt, aber deine DB markiert die Bestellung nicht als bezahlt, sodass die Erfüllung stockt. Behandle Webhook‑Handling als Pflicht.
Fünf Fallen, auf die du achten solltest:
Beispiel: Ein Kunde schließt den Tab nach der Zahlung, bevor die Erfolgsseite geladen wird. Ohne Webhooks denkt er, die Zahlung sei fehlgeschlagen, versucht es erneut und du bekommst möglicherweise doppelte Belastungen.
Wenn du mit Koder.ai baust, nutze Snapshots und Rollback als Teil deiner Routine: kleine Änderungen veröffentlichen, eine bekannte gute Version behalten und schnell wiederherstellen, falls etwas kaputtgeht.
Führe diese Checks zuerst in Staging durch und wiederhole sie kurz bevor du auf Live schaltest. Ziel: ein Kunde zahlt einmal, du zeichnest es einmal auf, und du kannst es erfüllen.
Starte mit dem Käuferpfad. Lege ein Produkt in den Warenkorb, schließe den Checkout ab und bestätige, dass du auf einer klaren Erfolgsseite landest. Bestätige, dass die bezahlte Bestellung im Admin mit den korrekten Summen erscheint.
Teste Webhooks „hart": Verzögerungen und Wiederholungen. Webhooks können spät, zweimal oder in falscher Reihenfolge ankommen. Deine Bestellaktualisierungslogik sollte idempotent sein, damit Wiederholungen nie doppelte bezahlte Bestellungen erzeugen.
Pre‑Launch‑Checklist:
Mache eine echte Live‑Belastung, bevor du etwas ankündigst. Nutze eine echte Karte, einen kleinen Betrag und deine eigene Versandadresse. Du solltest die Bestellung genau einmal sehen, mit klarem Zeitstempel und Status.
Wenn du Koder.ai verwendest, probiere das mit Snapshots: deployen, eine Bestellung platzieren, zurückrollen und bestätigen, dass bestehende Bestellungen weiterhin korrekt geladen werden.
Stell dir eine kleine Kaffeerösterei vor, die 12 Beutel Bohnen online verkaufen will. Sie braucht keine Abos, Bewertungen oder Loyalitätsprogramme. Sie braucht einen einfachen Shop, der echtes Geld annimmt und saubere Bestellungen erzeugt, die sie erfüllen kann.
Bis Tag 2 ist der Katalog gut genug, wenn jedes Produkt ein klares Foto, einen Preis und eine kurze Beschreibung (Röstgrad, Verkostungsnoten, Beutelgröße) hat. Halte Optionen minimal: eine Größe pro Produkt und eine Versandoption (z. B. Pauschalversand in einem Land).
Bis Tag 4 macht der Checkout eine Sache: Versanddetails sammeln, Kartenabrechnung durchführen und eine Bestätigungsseite zeigen, die der Kunde screenshotten kann. Zeige eine Bestell‑ID und eine kurze Zusammenfassung (Artikel, Gesamt, Versandadresse). Wenn ein Kunde Support‑E‑Mail schreibt, ist die Bestell‑ID der schnellste Weg, herauszufinden, was passiert ist.
Bis Tag 5 bleibt das Admin absichtlich schlicht. Der Röster loggt sich ein, sieht neue Bestellungen und verschiebt sie durch paid, packed, shipped. Tracking kann später kommen. In Woche eins reicht oft eine Notiz wie „Versendet via Post, Label gedruckt um 15:10".
Das ist auch der Scope, der gut mit chat‑first Buildern wie Koder.ai funktioniert: wenige Screens, wenige Tabellen und ein klarer Workflow.
Woche‑2‑Ideen, die warten dürfen: Rabattcodes, bessere Suche, Inventarzähle und mehr automatisierte E‑Mails. Füge sie erst hinzu, wenn echte Bestellungen zeigen, was wirklich wichtig ist.
Behandle die erste Live‑Woche als Lern‑Sprint. Lass echte Bestellungen durch das System laufen und beseitige dann die größte Reibung, die du beweisen kannst.
Starte mit einem kleinen Pilot: Ziele auf 10 bezahlte Bestellungen von Freunden, Kollegen oder einem kleinen Publikum, das du direkt ansprechen kannst. Frage jeden, wo er gezögert hat. Verfolge Abbrüche in einer einfachen Tabelle: Produktseite -> Warenkorb -> Checkout gestartet -> Zahlung erfolgreich.
Nach dem Pilot ändere jeweils nur eine Sache. Die besten frühen Verbesserungen sind meist einfach: klarere Versandkosten, bessere Produktfotos, weniger Checkout‑Felder. Wähle den nächsten größten Blocker aus deinen Notizen, behebe ihn und starte eine weitere kleine Charge.
Der Kundensupport zeigt dir auch schnell, was fehlt. Lege kurze Antworten für wiederkehrende Fragen bereit: Wo ist meine Bestellung, kann ich stornieren, warum ist die Zahlung fehlgeschlagen, wieviel kostet Versand und wann kommt es an, kann ich die Adresse ändern.
Wenn du schnell iterieren willst ohne den Checkout zu riskieren, kann Koder.ai dir helfen, die nächste Version aus dem Chat zu generieren und Snapshots/Rollback zu nutzen, damit du Änderungen sicher testen kannst, bevor du sie live schaltest.
Ein „echtes" MVP ist eines, bei dem ein Fremder erfolgreich zahlen kann, du eine bezahle Bestellung mit korrekten Beträgen und Versanddaten sehen kannst und du die Bestellung am selben Tag erfüllen kannst, ohne zu raten.
Wenn du 10 Bestellungen in Folge ohne manuelle Korrekturen abwickeln kannst, bist du in einer hervorragenden Ausgangslage.
Wähle ein Land, eine Währung und eine Zahlungsart (meist Karten). Halte Versand und Steuern auf einer einfachen Regel (z. B. Pauschalversand und falls möglich Steuern = 0).
Der Scope bleibt klein, wenn jede Entscheidung den Fluss unterstützt: Produkt → Warenkorb → Checkout → bezahlte Bestellung → Erfüllung.
Beginne mit:
Überspringe Accounts, Wunschlisten, Bewertungen, Gutscheine, mehrere Währungen und mehrere Zahlungsarten in Woche eins.
Hosted Checkout ist in der Regel die Standardwahl für ein 7‑Tage‑MVP, weil es schneller ist und viele Sicherheits‑ und UI‑Randfälle vom Anbieter gehandhabt werden.
Eingebettete Kartenformulare wirken nativer, bringen aber meist mehr Fehlerquellen und Mehraufwand für sichere Handhabung mit sich.
Behandle den Webhook als die Quelle der Wahrheit. Redirect‑Seiten sind gut für die Nutzererfahrung, aber nicht zuverlässig (Tabs schließen, Netzwerkfehler).
Markiere die Bestellung erst nach Verifikation des Webhook‑Events als bezahlt und nachdem Betrag und Währung abgeglichen wurden.
Nutze einen idempotenten Webhook‑Handler:
So vermeidest du doppelte E‑Mails, doppelte Versendungen und verwirrende „zweimal bezahlt“‑Fälle.
Speichere Snapshots zum Kaufzeitpunkt:
Rechne nicht später neu aus der Product‑Tabelle, denn Preise und Regeln ändern sich und führen zu Inkonsistenzen.
Halte die Status einfach und auf die Erfüllung ausgerichtet:
Admin sollte drei Fragen schnell beantworten: Was wird verkauft, was wurde bezahlt, was muss versendet werden.
Minimale Admin‑Funktionen:
Charts und komplexe Rollen überspringen in Woche eins.
Eine einfache, sichere Routine:
Wenn du Koder.ai nutzt, erstelle vor jeder größeren Änderung einen , damit du bei Problemen schnell zurück kannst.
new, paid, packed, shipped, canceled (füge refunded nur hinzu, wenn du Rückerstattungen wirklich unterstützt)created, paid, failed, canceled, refundedDas Ziel ist, dass du auf einen Blick weißt, was als Nächstes zu tun ist.