E‑handels‑MVP på 7 dagar: en dag‑för‑dag‑plan för att lansera en liten butik med katalog, kassa, riktiga betalningar, grundläggande admin och säkrare releaser.
För en e‑handels‑MVP du kan färdigställa på en vecka betyder “verkliga betalningar” en sak: en riktig kund kan betala, du kan se ordern och du kan skicka den utan att gissa.
Håll första versionen snäv: ett land, en valuta och en betalmetod (vanligtvis kort). Om du försöker stödja allt kommer du att spendera veckan på kantfall istället för att sälja.
Den kortaste vägen är en liten butik som bara gör de steg som krävs för att flytta pengar och trigga uppfyllelse:
”Färdig” är inte ett perfekt butiksyta. ”Färdig” är att ta emot en order, debitera framgångsrikt och uppfylla den samma dag med den information du samlat in. Om du kan göra det för 10 ordrar i rad utan manuella åtgärder har du en fungerande MVP.
För att skydda det målet, bestäm i förväg vad som är utanför scope. Dessa funktioner känns standard, men de krävs inte för att få betalt denna vecka: önskelistor, recensioner, avancerad sökfunktion, komplexa lagerregler, kuponger, flera betalmetoder och flera valutor.
Välj en enhet att prioritera först. Om de flesta köpare kommer från sociala annonser, satsa på mobil‑först webb. Om du säljer till företag kan desktop‑först vara fint. Oavsett vilket, designa för en skärmstorlek först, sedan justera.
Om du bygger med ett chatt‑baserat verktyg som Koder.ai, skriv ner scopet innan du genererar skärmar och flöden. Ett strikt scope är det enklaste sättet att stoppa “bara en funktion till” från att bli dag 8.
En e‑handels‑MVP är ”verklig” när en främling kan hitta en produkt, betala och du kan uppfylla ordern utan fram och tillbaka‑mail.
Börja med produkter. Du behöver en titel, ett pris, en huvudbild, en kort beskrivning och en på/av‑knapp så du kan dölja artiklar utan att radera dem. Spara varianter, paket och komplex prissättning till senare.
Din katalog kan vara enkel: en produktslista och en produktsida. Grundläggande filter (som kategori eller i lager) är okej, men bygg inte en full sökmotor i vecka ett.
Kundvagn och kassa ska vara tråkiga och förutsägbara. Kundvagnen måste stödja lägg till, ta bort, ändra antal och visa en tydlig delsumma. För frakt och skatt, välj en enkel regel först (t.ex. fast frakt och skatt bara om du måste).
Ett minimalt end‑to‑end‑flöde behöver vanligtvis:
Admin är där MVP:er ofta fallerar. Du behöver inte diagram. Du behöver en låst inloggning, ett sätt att lägga till/ändra produkter och en orderlista där du kan ändra status (ny, betald, skickad, återbetald).
Exempel: du säljer tre ljus. Varje har ett foto och ett pris. En köpare lägger till två, ser en fast fraktavgift på $5, anger sin adress, betalar, och du markerar ordern som skickad efter att ha skrivit ut fraktsedeln.
Om du använder en vibe‑kodningsplattform som Koder.ai, håll prompten strikt: ”Endast dessa sidor, endast dessa fält, inga konton, inga kuponger, inga önskelistor.”
Betalningar är platsen att undvika kreativitet. Välj en leverantör du snabbt kan komma igång med och skicka endast kortbetalningar. Digitala plånböcker, delbetalning och banköverföringar kan vänta.
Det största valet är betalningsflödet:
Behandla betalningar som ett litet antal tillstånd du kan förstå vid en blick: created, paid, failed, canceled, refunded.
Spara bara vad du behöver för avstämning och support: leverantörens betalnings‑ID, valfri leverantörs kund-/session‑ID, belopp, valuta och ditt interna order‑ID. Spara aldrig råa kortuppgifter och uppfinna inte egna betalningsfält om du inte verkligen behöver dem.
Webhooks gör ordern pålitliga. Efter kassa, anta inte att en browser‑omdirigering betyder “betald.” Lägg till en webhook‑handler som verifierar händelsen och sedan markerar matchande order som betald.
Gör det säkert vid omleveranser. Webhooks kommer levereras mer än en gång, så din handler bör vara idempotent: om en order redan är betald ska den inte göra något och ändå returnera succé.
Om du bygger snabbt med en chattdriven byggare som Koder.ai, definiera betalningsstatusar och minimala fält först, generera sedan webhook‑endpoint och logiken för orderuppdatering. Den tydligheten förhindrar klassikern: betalda kunder, obetalda order och timmar av manuell kontroll.
Dag 1: lås scope. Skriv en en‑sides spec: vad en shoppare kan göra, vad en admin kan göra och vad som är utanför scope. Välj en betalningsleverantör. Bestäm hur du räknar totalsummor (skatt/frakt nu eller senare). Skissa fem nyckelskärmar: katalog, produktsida, kundvagn, kassa, betalningsresultat.
Dag 2: leverera katalogen. Spara produkter med bara de fält du behöver: namn, pris, valuta, foto, kort beskrivning, aktiv‑flagga. Bygg en ”alla produkter”‑sida (eller enkla kategorier) och en produktdetaljsida. Lägg in cirka 10 testprodukter så du kan testa riktiga flöden.
Dag 3: kundvagn och orderutkast. Implementera lägg till/ta bort och ändra antal. När kassan startar, skapa ett orderutkast och snapshotta priser så senare produktändringar inte ändrar gamla order. Captura kundens e‑post och leveransadress tidigt.
Dag 4: betalningar i testläge. Koppla kassan till betalningsskapande. Hantera success, canceled och failed betalningar. Spara betalningsstatus på ordern. Visa en tydlig bekräftelsesida med ordernummer och nästa steg.
Dag 5: grundläggande admin för uppfyllelse. Håll admin liten: skapa/ändra/avaktivera produkter, en orderlista med statusuppdateringar (paid, packed, shipped, refunded) och en enkel ”visa order”‑sida med vad du behöver för att skicka.
Dag 6: deploy och säkerhet. Sätt upp separata staging‑ och produktionsmiljöer, slå på loggar och repetera hela flödet med testkort. Skriv en rollback‑plan innan du behöver den.
Dag 7: gå live (litet, kontrollerat). Gör en sista genomgång med ett riktigt, lågbelopp köp, bekräfta e‑post/kvittenser och öppna butiken för en liten publik först. Om du använder Koder.ai, ta en snapshot innan varje större ändring så du snabbt kan rulla tillbaka om kassan slutar fungera.
En vecka‑ett butik lever eller dör på orderklarhet. När någon betalar ska du snabbt kunna svara: vad köpte de, vart skickas det och vad är nuvarande status?
Börja med en liten, tråkig datamodell. Dessa fem poster täcker nästan allt:
Håll adresser minimala så kassan förblir snabb. Du behöver vanligtvis bara namn, line1, stad, postnummer och land. Telefon kan vara valfritt om inte din transportör kräver det.
Spara totalsummor som snapshot vid köptillfället. Räkna inte om totalsummor senare från Product‑tabellen. Priser ändras, fraktpriser justeras och du kommer få ”kunden betalade X men ordern säger nu Y.” Spara enhetspris per vara samt orderns subtotal, frakt, skatt (även om noll) och totalsumma.
Använd tydliga statusar som matchar uppfyllelse, inte betalningsleverantörens jargong: new, paid, packed, shipped, canceled. Lägg till refunded först när du verkligen stödjer det.
Planera för idempotens i betalningsuppdateringar. Samma webhook kan komma två gånger eller i fel ordning. Spara ett unikt event‑ID från leverantören och ignorera dubbletter.
Exempel: en webhook markerar betalning “succeeded” två gånger. Ditt system ska inte skapa två leveranser eller skicka två bekräftelsemail. Om du bygger på Koder.ai med en Go‑backend och PostgreSQL är en unik constraint på (provider, raw_event_id) plus en transaktion runt statusuppdateringen ofta tillräckligt.
Admin är inte en ”dashboard.” Det är ett litet bakrum där du snabbt svarar tre frågor: vad säljs, vad blev betalt och vad behöver skickas.
Börja med en enda admininloggning. En roll räcker. Använd ett starkt lösenord, grundläggande rate limiting och kort sessions‑timeout. Hoppa över personalhantering och behörigheter denna vecka. Om du behöver en andra person, dela åtkomsten med avsikt och rotera lösenordet senare.
Håll produktadministration enkel: skapa/ändra produkter, ladda upp en huvudbild, sätt pris, slå på/av tillgänglighet. För lager, bygg inte räkningar om du inte verkligen har dem. En i lager/ur lager‑växel förhindrar vanligtvis översälj.
Din ordervy bör läsa som en packsedel. Gör det enkelt att söka på order‑ID eller kundens e‑post, och visa sedan:
För statusåtgärder, håll det till två knappar: ”Markera packad” och ”Markera skickad”. När du markerar skickad, spara valfritt en spårningsnotering (transportör + spårningskod, eller ”Upphämtning arrangerad”). Automatiska mejl kan vänta om de kommer sakta ner dig.
CSV‑export är valfritt. Lägg till det bara om du vet att du kommer använda det vecka ett.
Om du använder ett byggverktyg som Koder.ai, håll admin i samma app men lås den bakom en skyddad route och kräva en giltig session.
Börja i testläge. Ditt mål är inte ”en kassasida.” Ditt mål är en order som är betald, registrerad och redo att uppfyllas.
Gör en strikt regel: spara aldrig råa kortuppgifter på din server. Använd hosted checkout eller klient‑sidig tokenisering så känsliga data går direkt till betalningsleverantören.
Logga betalningsfel med kontext du kan agera på: order‑ID, session‑ID, kund‑e‑post (om tillgängligt), förväntad totalsumma, leverantörsfelkod och ett kort meddelande som ”Beloppsmismatch” eller ”Webhook‑signature invalid.”
Exempel: en kund försöker köpa två muggar. Din server räknar $24 + frakt, skapar sessionen och sparar en order som pending. Om kunden stänger sidan blir ordern canceled. Om de betalar, vänder webhooken den till paid och du kan uppfylla den med självförtroende.
När du bara har en vecka kan driftsättningar tyst bli det som bryter kassan. Målet är inte fint DevOps. Det är en upprepad rutin som minskar överraskningar och ger en utrymningsväg.
Sätt upp två miljöer: staging och production. Staging ska vara så lik production som möjligt: samma inställningar, samma mallar, samma skatt/fraktregler, men betalningar i testläge. Kör slutliga kontroller i staging och promotera sedan exakt samma build till production.
Använd versionshanterade releaser. Även om det bara är v1, v2, v3, tagga varje release och håll föregående redo. Rollback ska vara en handling: växla tillbaka till föregående build eller återställ en snapshot. Om din plattform stöder snapshots och rollback (Koder.ai gör det), gör det till en vana att ta snapshot precis före varje produktionrelease.
Behandla databasmigrationer som riskabla under MVP‑veckan. Föredra bakåtkompatibla förändringar: lägg till nya tabeller eller kolumner, byt inte namn eller ta bort än och håll gamla kodvägar fungerande tills den nya releasen är stabil. Om du behöver fylla data, gör det i ett separat jobb, inte inne i en request.
Håll hemligheter utanför repo. Använd miljövariabler eller en secret manager för API‑nycklar, webhook‑signeringshemligheter, databas‑URL:er och adminlösenord.
Release‑checklista:
Det snabbaste sättet att missa ett 7‑dagarsmål är att bygga ”fina” funktioner som tyst bryter pengaflödet. Poängen är en butik som tar betalt, skapar en pålitlig order och låter dig uppfylla den.
Ett vanligt misstag är att låta webbläsaren bestämma slutpriset. Om totalsummor, rabatter eller frakt räknas i klienten kommer någon till slut att betala fel belopp. Gör servern till enda sanningskälla: bygg upp ordern från produkt‑ID:n och kvantiteter, räkna totalsummor igen innan du skapar en betalning.
Frakt‑ och skatteregler är en annan tidsfälla. Team förlorar dagar på att försöka stödja varje land och kantfall. För vecka ett, välj en enkel regel och håll dig till den.
Betalningar kan också ”fungera” i kassan men misslyckas i drift om webhooks saknas. En kund betalar, men din databas markerar aldrig ordern betald, så uppfyllelse stannar. Behandla webhook‑hantering som obligatorisk.
Fem fallgropar att se upp för:
Exempel: en kund slutför betalningen och stänger fliken innan lyckosidan laddas. Utan webhooks antar de att den misslyckades, försöker igen och du kan få dubbla debiteringar.
Om du bygger med Koder.ai, använd snapshots och rollback som en del av din rutin: släpp små ändringar, behåll en känd fungerande version och återställ snabbt om något går sönder.
Gör dessa kontroller i staging först, upprepa dem sedan precis innan du växlar till live. Målet är enkelt: en kund betalar en gång, du registrerar den en gång och du kan uppfylla den.
Börja med köparens väg. Lägg till en produkt i kundvagnen, slutför kassan och se till att du landar på en tydlig succé‑sida. Bekräfta att du kan se den betalda ordern i admin med rätt totalsummor.
Testa sedan webhooks på riktigt: fördröjningar och omleveranser. Webhooks kan komma sent, komma två gånger eller i fel ordning. Din orderuppdateringslogik ska vara idempotent så retries aldrig skapar dubbletter.
Pre‑launch‑checklista:
Gör en riktig live‑debitering innan du annonserar något. Använd ett riktigt kort, ett litet belopp och din egen leveransadress. Du ska se ordern visa sig exakt en gång, med tydlig tidsstämpel och status.
Om du använder Koder.ai, öva detta med snapshots: deploya, placera en order, rulla tillbaka och bekräfta att befintliga order fortfarande laddas korrekt.
Föreställ dig en liten kafferostare som vill sälja 12 paket bönor online. De behöver inte prenumerationer, recensioner eller lojalitetsprogram. De behöver en enkel butik som tar riktiga pengar och skapar rena order de kan uppfylla.
Dag 2 räcker katalogen om varje produkt har en tydlig bild, ett pris och en kort beskrivning (rostgrad, smaknoter, paketstorlek). Håll alternativ minimala: en storlek per produkt och ett fraktalternativ (t.ex. fast frakt inom ett land).
Dag 4 gör kassan en sak: samla leveransdetaljer, ta ett kortbetalning och visa en bekräftelsesida kunden kan skärmdumpa. Visa ett order‑ID och en kort sammanfattning (artiklar, total, leveransadress). Om en kund mailar support är det order‑ID det snabbaste sättet att hitta vad som hänt.
Dag 5 håller admin medvetet enkel. Rostaren loggar in, ser nya order och flyttar dem genom paid, packed, shipped. Spårning kan komma senare. I vecka ett räcker en notering som ”Skickat via posttjänst, fraktsedel utskriven kl 15:10”.
Detta är också ett scope som fungerar väl med chatt‑först byggare som Koder.ai: ett litet set skärmar, ett litet set tabeller och ett klart arbetsflöde.
Vecka 2‑idéer värda att vänta på: rabattkoder, bättre sökning, lagerantal och fler automatiska mejl. Lägg till dem först efter att riktiga order visat vad som verkligen betyder något.
Behandla den första veckan live som en lärande‑sprint. Få riktiga order genom systemet, ta bort det största friktionen du kan bevisa.
Börja med en liten pilot: sikta på 10 betalda order från vänner, kollegor eller en liten publik du kan kontakta direkt. Fråga varje person var de tvekade. Spåra bortfall i ett enkelt ark: produktsida -> kundvagn -> kassa startad -> betalning lyckades.
Efter piloten, lägg till bara en ändring i taget. De bästa tidiga förbättringarna är ofta enkla: tydligare fraktkostnader, bättre produktbilder, färre fält i kassan. Välj nästa största hinder från dina anteckningar, åtgärda det och kör en ny liten batch.
Kundsupport visar också snabbt vad som saknas. Spara korta svar på de frågor du ofta får: var är min order, kan jag avboka, varför misslyckades betalningen, hur mycket är frakt och när kommer paketet, kan ni ändra min adress.
Om du vill iterera snabbt utan att riskera kassan kan Koder.ai hjälpa dig generera nästa version från chatten och använda snapshots och rollback så du kan testa ändringar säkert innan du pushar live.
En “verklig” MVP är en där en främling kan betala framgångsrikt, du kan se en betald order med rätt totalsummor och leveransuppgifter, och du kan uppfylla den samma dag utan gissningar.
Om du kan köra 10 ordrar i rad utan manuella åtgärder är du i ett mycket bra läge.
Välj ett land, en valuta och en betalmetod (vanligtvis kort). Håll frakt och skatt till en enkel regel (t.ex. fast frakt och skatt = 0 om du kan).
Scope förblir litet när varje beslut stödjer: produkt → kundvagn → kassa → betald order → uppfyllelse.
Börja med:
Hoppa över konton, önskelistor, recensioner, kuponger, flera valutor och flera betalmetoder.
Hosted checkout är oftast standard för en 7‑dagars MVP eftersom det är snabbare och minskar säkerhets‑ och UI‑edgecases.
Inbäddade kortformulär kan se mer “native” ut, men de ger oftast fler felkällor och mer arbete för säkerheten.
Behandla webhooken som sanningskällan. Omdirigeringssidor är bra för användarupplevelsen, men de är inte pålitliga (flikar stängs, nätverk fallerar).
Använd en webhook för att markera ordern betald först efter att du verifierat händelsen och matchat förväntat belopp/valuta.
Använd en idempotent webhook‑handler:
Detta förhindrar dubbla mejl, dubbla leveranser och förvirrande “betald två gånger”‑situationer.
Spara snapshots vid köptillfället:
Räkna inte om totalsummor senare från Produkt‑tabellen, eftersom priser och regler ändras och du då får mismatchade poster.
Håll statusarna enkla och uppfyllelsefokuserade:
Admin ska snabbt svara tre frågor: vad säljs, vad blev betalt, vad behöver skickas.
Minsta adminfunktioner:
Hoppa över diagram och komplexa roller vecka ett.
En enkel, säker rutin:
Om du använder Koder.ai, ta en före varje större ändring så du snabbt kan rulla tillbaka om checkout slutar fungera.
new, paid, packed, shipped, canceled (lägg till refunded bara om du verkligen stödjer återbetalningar)created, paid, failed, canceled, refundedMålet är att du ska kunna titta på en order och veta vad som ska göras härnäst.