Ecommerce MVP in 7 dagen: een kleine winkel met echte betalingen opleveren

Wat je oplevert (en wat niet)

Voor een ecommerce MVP die je in een week kunt afronden, betekent “echte betalingen” één ding: een echte klant kan betalen, jij ziet de order, en je kunt die verzenden zonder te gokken.

Houd de eerste versie smal: één land, één valuta en één betaalmethode (meestal kaarten). Als je alles probeert te ondersteunen, besteed je de week aan randgevallen in plaats van aan verkopen.

Het kortste pad is een kleine winkel die alleen doet wat nodig is om geld te verplaatsen en fulfilment te triggeren:

• Een productpagina met een duidelijke prijs en voorraadstatus
• Een winkelwagen die hoeveelheid kan wijzigen en totalen toont
• Een checkout die naam, e-mail en verzendadres verzamelt
• Een bevestigingspagina (plus een e-mailbewijs als je dat kunt)

“Klaar” is geen perfecte etalage. “Klaar” is een order aannemen, succesvol afrekenen en dezelfde dag verwerken met de informatie die je verzamelde. Als je dat 10 orders achter elkaar kunt doen zonder handmatige fixes, heb je een werkende MVP.

Om dat doel te beschermen, beslis vooraf wat buiten scope valt. Deze functies voelen standaard aan, maar zijn niet vereist om deze week betaald te worden: verlanglijstjes, reviews, geavanceerd zoeken, complexe voorraadregels, coupons, meerdere betaalmethoden en meerdere valuta.

Kies eerst één apparaattarget. Als de meeste kopers via social ads komen, kies dan mobile-first web. Als je aan bedrijven verkoopt, is desktop-first prima. Ontwerp in elk geval eerst voor één schermgrootte en pas later aan.

Als je bouwt met een chat-gebaseerde tool zoals Koder.ai, schrijf de scope op voordat je schermen en flows genereert. Een strikte scope is de makkelijkste manier om te voorkomen dat “nog één feature” verandert in dag 8.

De kleinste featureset die nog werkt

Een ecommerce MVP is “echt” wanneer een vreemde een product kan vinden, betalen en jij de order zonder heen-en-weer mailen kunt uitleveren.

Begin met producten. Je hebt een titel nodig, een prijs, één hoofdafbeelding, een korte omschrijving en een aan/uit-schakelaar zodat je items kunt verbergen zonder ze te verwijderen. Varianten, bundels en complexe prijsafspraken kun je bewaren voor later.

Je catalogus kan eenvoudig blijven: een productlijstpagina en een productdetailpagina. Basisfilters (zoals categorie of op voorraad) zijn prima, maar bouw geen volledige zoekmachine in week één.

Winkelwagen en checkout moeten saai en voorspelbaar zijn. De winkelwagen moet toevoegen, verwijderen, hoeveelheid wijzigen ondersteunen en een duidelijke subtotalen tonen. Voor verzending en belasting kies je eerst één eenvoudige regel (bijvoorbeeld vaste verzendkosten en belasting alleen als het echt nodig is).

Een minimale end-to-end flow heeft meestal nodig:

• Productlijst
• Productdetail
• Winkelwagen
• Checkout (klantinformatie + verzendadres + overzicht)
• Admin-gebied (producten en orders)

Admin is waar MVP’s vaak falen. Je hebt geen grafieken nodig. Je hebt een beveiligde login nodig, een manier om producten toe te voegen/bewerken en een orderlijst waar je de status kunt veranderen (nieuw, betaald, verzonden, terugbetaald).

Voorbeeld: je verkoopt drie kaarsen. Elk heeft één foto en één prijs. Een koper voegt er twee toe, ziet een vaste verzendkosten van $5, voert z’n adres in, betaalt, en jij markeert de order als verzonden nadat je het etiket hebt geprint.

Als je een vibe-coding platform zoals Koder.ai gebruikt, houd het prompt strikt: “Alleen deze pagina’s, alleen deze velden, geen accounts, geen coupons, geen verlanglijstjes.”

Betalingen: houd het echt, houd het saai

Betalingen zijn de plek om creativiteit te vermijden. Kies één provider die je snel kunt onboarden en lever alleen kaartbetalingen. Digitale wallets, achteraf betalen en bankoverschrijvingen kunnen wachten.

De grootste keuze is de betaalstroom:

• Hosted checkout is meestal het snelst en veiligst, omdat de provider het meeste gevoelige UI-werk afhandelt.
• Ingebedde kaartformulieren kunnen er mooier uitzien, maar ze voegen meer randgevallen en meer securitywerk toe.

Behandel betalingen als een kleine set statussen die je in één oogopslag begrijpt: aangemaakt, betaald, mislukt, geannuleerd, terugbetaald.

Sla alleen op wat je nodig hebt voor reconciliatie en support: de provider payment ID, optioneel provider customer/session ID, bedrag, valuta en jouw interne order ID. Bewaar nooit ruwe kaartgegevens en verzin geen eigen betaalvelden tenzij je ze echt nodig hebt.

Webhooks maken orders betrouwbaar. Neem na checkout niet aan dat een browserredirect “betaald” betekent. Voeg een webhook-handler toe die het event verifieert en daarna de bijbehorende order als betaald markeert.

Maak het veilig tegen herleveringen. Webhooks worden soms meer dan eens afgeleverd, dus je handler moet idempotent zijn: als een order al betaald is, doet hij niets en geeft toch succes terug.

Als je snel bouwt met een chat-gestuurde builder zoals Koder.ai, definieer dan eerst betaalstatussen en minimale velden en genereer vervolgens de webhook-endpoint en order-update-logica. Die duidelijkheid voorkomt de klassieke puinhoop: betaalde klanten, onbetaalde orders en uren handmatig controleren.

Dag-tot-dag plan voor de 7-daagse build

Dag 1: zet de scope vast. Schrijf een één-pagina spec: wat een shopper kan doen, wat een beheerder kan doen en wat buiten scope valt. Kies een betaalprovider. Beslis hoe je totalen berekent (belasting/verzending nu of later). Schets vijf sleutelpagina’s: catalogus, productpagina, winkelwagen, checkout, betaalresultaat.

Dag 2: lever de catalogus. Sla producten op met alleen de velden die je nodig hebt: naam, prijs, valuta, foto, korte beschrijving, active-flag. Bouw een “alle producten” pagina (of eenvoudige categorieën) en een productdetailpagina. Voeg ongeveer 10 testproducten toe zodat je echte flows kunt testen.

Dag 3: winkelwagen en order-drafts. Implementeer toevoegen/verwijderen en hoeveelheid wijzigen. Wanneer checkout start, maak een order-draft en neem prijzen op als snapshot zodat latere productwijzigingen oude orders niet veranderen. Leg klant-e-mail en verzendadres vroeg vast.

Dag 4: betalingen in testmodus. Verbind de checkout aan payment creation. Handel successen, geannuleerd en mislukte betalingen af. Sla betalingsstatus op de order. Toon een duidelijke bevestigingspagina met ordernummer en vervolgstappen.

Dag 5: basisbeheer voor fulfilment. Houd admin klein: product aanmaken/bewerken/uitschakelen, een orderlijst met statusupdates (betaald, ingepakt, verzonden, terugbetaald) en een simpele “order bekijken” pagina met wat je nodig hebt om te verzenden.

Dag 6: deployment en veiligheid. Zet aparte staging- en production-omgevingen op, zet logging aan en voer de hele flow uit met testkaarten. Schrijf een rollback-plan voordat je het nodig hebt.

Dag 7: live gaan (klein, gecontroleerd). Doe een laatste doorloop met een echte lage-waarde aankoop, controleer e-mails/bewijzen en open de winkel eerst voor een klein publiek. Als je Koder.ai gebruikt, maak voor elke grote wijziging een snapshot zodat je snel terug kunt als de checkout faalt.

Gegevens die je moet opslaan om rommelige orders te vermijden

Een week-één winkel leeft of sterft op duidelijkheid van orders. Zodra iemand betaalt, moet je snel kunnen antwoorden: wat kochten ze, waar moet het naartoe en wat is de huidige status?

Begin met een klein, saai datamodel. Deze vijf records dekken bijna alles:

• Product: id, titel, prijs, valuta, active
• Klant: id, e-mail, naam (optioneel)
• Order: id, klant_id (of e-mail), verzendadresvelden, status, totals snapshot, created_at
• OrderItem: order_id, product_id, title_snapshot, unit_price_snapshot, quantity
• Payment: order_id, provider, provider_payment_id, amount, currency, status, raw_event_id

Houd adressen minimaal zodat checkout snel blijft. Gewoonlijk heb je alleen naam, adresregel1, stad, postcode en land nodig. Telefoon kan optioneel zijn tenzij je vervoerder het vereist.

Leg totalen vast als snapshot op het moment van aankoop. Herbereken later niet vanuit de Product-tabel. Prijzen veranderen, verzendtarieven worden aangepast en je eindigt met “de klant betaalde X maar de order zegt nu Y.” Bewaar unit price per item, plus order subtotal, verzending, belasting (ook als 0) en het eindtotaal.

Gebruik duidelijke statussen die bij fulfilment passen, niet bij betalingleveranciers-jargon: nieuw, betaald, ingepakt, verzonden, geannuleerd. Voeg terugbetaald alleen toe als je het echt ondersteunt.

Plan idempotentie in voor betalingupdates. Dezelfde webhook kan twee keer of in verkeerde volgorde arriveren. Sla een uniek event-ID van de provider op en negeer duplicaten.

Voorbeeld: een webhook markeert betaling twee keer als “geslaagd”. Je systeem zou niet twee zendingen moeten aanmaken of twee bevestigingsmails sturen. Als je bouwt met Koder.ai met een Go-backend en PostgreSQL, is een unieke constraint op (provider, raw_event_id) plus een transactie rond de statusupdate vaak voldoende.

Basisbeheer: alleen wat helpt bij fulfilment

Admin is geen “dashboard.” Het is een kleine achterkamer waarin je drie vragen snel beantwoordt: wat is te koop, wat is betaald en wat moet verzonden worden.

Begin met één admin-login. Eén rol is genoeg. Gebruik een sterk wachtwoord, basis rate limiting en een korte sessietimeout. Sla personeelsbeheer en permissies over deze week. Als je iemand anders nodig hebt, deel de toegang bewust en roteer later het wachtwoord.

Houd productbeheer simpel: maak/bewerk producten, upload één hoofdafbeelding, zet prijs, schakel beschikbaarheid aan/uit. Voor voorraad bouw geen aantallen tenzij je die echt hebt. Een op-voorraad/niet-op-voorraad-schakelaar voorkomt meestal overselling.

Je orderweergave moet lezen als een pakbon. Maak het makkelijk om te zoeken op order-ID of klant-e-mail, en toon daarna:

• Klantnaam, e-mail, verzendadres
• Artikelen, aantallen en definitieve totalen (inclusief verzending en belasting)
• Betalingsstatus (betaald, mislukt, terugbetaald)
• Fulfillmentstatus (nieuw, ingepakt, verzonden)
• Timestamps en een korte interne notitie

Voor statusacties houd het bij twee knoppen: “Markeer ingepakt” en “Markeer verzonden.” Wanneer je op verzonden zet, bewaar optioneel een trackingnotitie (vervoerder + trackingcode, of “Afhalen geregeld”). Geautomatiseerde e-mails kunnen wachten als ze je vertragen.

CSV-export is optioneel. Voeg het alleen toe als je zeker weet dat je het in week één gaat gebruiken.

Als je een bouwtool als Koder.ai gebruikt, houd admin in dezelfde app, maar beveilig het achter een beschermde route en eis een geldige sessie.

Stapsgewijs: zorg voor de eerste succesvolle betaling

Begin in testmodus. Je doel is niet “een checkoutpagina.” Je doel is één order die betaald is, opgeslagen en klaarstaat om te vervullen.

Maak één harde regel: bewaar nooit ruwe kaartgegevens op je server. Gebruik hosted checkout of client-side tokenisatie zodat gevoelige data direct naar de payment provider gaat.

Het pad naar je eerste betaalde order

1. Maak een testproduct en prijs op de server. Checkout moet prijzen uit je database ophalen, niet uit de browser.
2. Start een checkout-sessie in testmodus. Je backend maakt de paymentsessie aan en geeft alleen terug wat de client nodig heeft om te redirecten.
3. Bescherm tegen dubbel klikken. Zet de Betaal-knop uit na de eerste klik. Gebruik een server-side idempotency-key (bijv. winkelwagen-ID plus een korte tijdsperiode) zodat duplicaten dezelfde sessie teruggeven in plaats van een tweede charge te maken.
4. Verifieer betaling op de server. Behandel de provider-webhook als de bron van waarheid. Markeer de order pas als betaald nadat je hebt bevestigd dat het event echt is en overeenkomt met het verwachte bedrag en valuta.
5. Test faalpaden. Voer een mislukte betaling uit, een geannuleerde checkout en een verlopen sessie. Elk moet eindigen in een duidelijke orderstatus, geen mysterie.

Maak fouten makkelijk te herstellen

Log paymentfouten met context waarop je kunt handelen: order-ID, sessie-ID, klant-e-mail (als beschikbaar), verwacht totaal, provider errorcode en een korte boodschap zoals “bedrag komt niet overeen” of “webhook signature ongeldig.”

Voorbeeld: een klant probeert twee mokken te kopen. Je server berekent $24 + verzending, maakt de sessie en registreert een order als pending. Als de klant de pagina sluit, wordt de order geannuleerd. Als ze betalen, draait de webhook hem naar betaald en kun je met vertrouwen vervullen.

Een veilige deployment workflow die je echt kunt volgen

Als je maar één week hebt, kunnen deployments heimelijk de checkout breken. Het doel is geen fancy DevOps. Het is een herhaalbare routine die verrassingen reduceert en je een uitweg geeft.

Zet twee omgevingen op: staging en production. Staging moet zo dicht mogelijk bij production staan: dezelfde instellingen, dezelfde templates, dezelfde belasting/verzendregels, maar betalingen in testmodus. Doe de laatste checks in staging en promoot dan exact dezelfde build naar production.

Gebruik versiegebonden releases. Zelfs als het alleen v1, v2, v3 is: tag elke release en houd de vorige klaar. Rollback moet één actie zijn: terugschakelen naar de vorige build of een snapshot herstellen. Als je platform snapshots en rollback ondersteunt (Koder.ai doet dat), maak er een gewoonte van om een snapshot te nemen vlak voor elke productie-release.

Behandel database-migraties als risicovol tijdens MVP-week. Geef de voorkeur aan achterwaarts compatibele veranderingen: voeg tabellen of kolommen toe, hernoem of verwijder nog niet, en houd oude codepaden werkend totdat de nieuwe release stabiel is. Als je data moet backfillen, doe het in een aparte job, niet binnen een request.

Houd secrets uit je repository. Gebruik environment variables of een secret manager voor API-sleutels, webhook signing secrets, database-URL’s en admin-wachtwoorden.

Release-checklist:

• Bevestig dat staging checkout end-to-end werkt met een testkaart en een webhook-event
• Voer migraties uit op staging, daarna production, en bevestig dat orderaanmaak nog steeds werkt
• Verifieer dat e-mails (orderbevestiging, mislukte betaling) verzonden worden en er goed uitzien
• Neem een pre-release snapshot en noteer de releaseversie
• Doe een snelle tweede review: één persoon pusht, een ander controleert de lijst

Veelvoorkomende valkuilen die een 7-daagse MVP vertragen

De snelste manier om een 7-daagse doel te missen is het bouwen van “mooie” features die stilletjes de geldstroom breken. Het punt is een winkel die betalingen accepteert, een betrouwbare order aanmaakt en je in staat stelt te verzenden.

Een veelgemaakte fout is de browser de definitieve prijs laten beslissen. Als totalen, kortingen of verzending aan de client worden berekend, zal iemand ooit het verkeerde bedrag betalen. Maak de server de enige bron van waarheid: bouw de order opnieuw op vanaf product-ID’s en hoeveelheden en bereken de totalen opnieuw voordat je een betaling aanmaakt.

Verzend- en belastingregels zijn een andere tijdbeslinder. Teams verliezen dagen aan het ondersteunen van elk land en elk randgeval. Kies voor week één één eenvoudige regel en houd je eraan.

Betalingen kunnen in de checkout “werken” maar falen in de operatie als webhooks ontbreken. Een klant betaalt, maar je database markeert de order nooit als betaald, dus fulfilment loopt vast. Behandel webhook-afhandeling als verplicht.

Vijf valkuilen om op te letten:

• Vertrouwen op client-side totalen in plaats van herberekenen op de server
• Complexe verzend- en belastingtabellen bouwen voordat er vraag is
• Webhooks overslaan en alleen vertrouwen op de “betaling geslaagd” redirect-pagina’s
• Vergeten een duidelijke orderbevestiging of e-mail te tonen
• Direct naar production deployen zonder rollback-pad

Voorbeeld: een klant rondt de betaling af en sluit dan het tabblad voordat de succespagina laadt. Zonder webhooks denken ze dat het mislukt is, proberen het nogmaals en je kunt dubbele kosten krijgen.

Als je met Koder.ai bouwt, gebruik snapshots en rollback als onderdeel van je routine: ship kleine veranderingen, houd een bekende goede versie en herstel snel als iets kapotgaat.

Snelle checks voordat je live betalingen aanzet

Doe deze checks eerst in staging en herhaal ze vlak voor je naar live schakelt. Het doel is simpel: één klant betaalt één keer, je registreert het één keer en je kunt het vervullen.

Begin met het koperspad. Voeg een product toe aan de winkelwagen, rond afrekenen af en zorg dat je op een duidelijke succespagina landt. Bevestig dat je de betaalde order in admin met de juiste totalen kunt zien.

Test dan webhooks op de harde manier: vertragingen en herleveringen. Webhooks kunnen laat, twee keer of in verkeerde volgorde arriveren. Je order-update-logica moet idempotent zijn zodat retries nooit dubbele betaalde orders maken.

Pre-launch checklist:

• Plaats een testorder end-to-end en bevestig dat deze in admin verschijnt met de transaction/payment ID opgeslagen
• Stuur hetzelfde webhook-event opnieuw en verifieer dat er niets dupliceert
• Schakel een product uit en bevestig dat het verdwijnt en niet gekocht kan worden
• In admin: zet een order door de statussen (nieuw -> betaald -> verzonden) en voeg een interne notitie toe
• Deploy een kleine wijziging en rol het binnen enkele minuten terug zonder orderdata te verliezen

Doe één echte live charge voordat je iets aankondigt. Gebruik een echte kaart, een klein bedrag en je eigen verzendadres. Je zou de order exact één keer moeten zien verschijnen, met een duidelijke timestamp en status.

Als je Koder.ai gebruikt, oefen dit met snapshots: deploy, plaats een order, rol terug en bevestig dat bestaande orders nog steeds correct laden.

Voorbeeldscenario: een kleine winkel die deze week kan verzenden

Stel je een kleine koffiebrander voor die 12 zakken bonen online wil verkopen. Ze hebben geen abonnementen, reviews of loyaliteitsprogramma nodig. Ze willen een simpele winkel die echt geld accepteert en schone orders creëert die ze kunnen verwerken.

Op dag 2 is de catalogus goed genoeg als elk product een duidelijke foto, een prijs en een korte beschrijving heeft (brandingsniveau, smaaknoten, zakgrootte). Houd opties minimaal: één maat per product en één verzendoptie (bijv. vaste verzendkosten in één land).

Op dag 4 doet de checkout één taak: verzendgegevens verzamelen, kaartbetaling innen en een bevestigingspagina tonen die de klant kan screenshotten. Toon een order-ID en een kort overzicht (artikelen, totaal, verzendadres). Als een klant support e-mailt, is dat order-ID de snelste manier om te vinden wat er gebeurde.

Op dag 5 blijft admin opzettelijk eenvoudig. De brander logt in, ziet nieuwe orders en zet orders door betaald, ingepakt, verzonden. Tracking kan later komen. In week één is een notitie als “Verzonden via post, etiket geprint om 15:10” vaak genoeg.

Dit is ook de scope die goed werkt met chat-first builders zoals Koder.ai: een kleine set schermen, een kleine set tabellen en een duidelijk workflow.

Week 2-ideeën die het wachten waard zijn: kortingscodes, betere zoekfunctie, voorraadtellingen en meer geautomatiseerde e-mails. Voeg ze pas toe nadat echte orders je vertellen wat belangrijk is.

Volgende stappen nadat de MVP live is

Behandel de eerste week live als een leersprint. Laat echte orders door het systeem lopen en verwijder daarna het grootste obstakel dat je kunt bewijzen.

Begin met een kleine pilot: mik op 10 betaalde orders van vrienden, collega’s of een klein publiek dat je direct kunt benaderen. Vraag elke persoon waar ze aarzelden. Volg uitval bij in een eenvoudige sheet: productpagina -> winkelwagen -> checkout gestart -> betaling succesvol.

Na de pilot voeg je steeds maar één verandering tegelijk toe. De beste vroege verbeteringen zijn meestal simpel: duidelijkere verzendkosten, betere productfoto’s, minder checkoutvelden. Kies de volgende grootste blocker uit je aantekeningen, los die op en voer een nieuw klein batchje uit.

Klantenservice laat ook snel zien wat ontbreekt. Bewaar korte antwoorden op vragen die vaak terugkomen: waar is mijn order, kan ik annuleren, waarom is betaling mislukt, hoeveel is verzending en wanneer komt het aan, kan je mijn adres aanpassen.

Als je snel wil itereren zonder checkout te riskeren, kan Koder.ai je helpen de volgende versie vanuit chat te genereren en snapshots/rollback te gebruiken zodat je wijzigingen veilig kunt testen voordat je ze live zet.