MVP e-commerce in 7 giorni: un piano giorno per giorno per lanciare un negozio minimale con catalogo, checkout, pagamenti reali, admin base e rilasci più sicuri.
Per un MVP e-commerce che puoi completare in una settimana, “pagamenti reali” significa una cosa: un cliente vero può pagare, tu vedi l'ordine e puoi spedirlo senza dover indovinare.
Mantieni la prima versione ristretta: un paese, una valuta e un metodo di pagamento (di solito carte). Se provi a supportare tutto, passerai la settimana sui casi limite invece di vendere.
La strada più corta è un negozio piccolissimo che fa solo i passaggi necessari per muovere il denaro e attivare l'evasione:
"Fatto" non è una vetrina perfetta. "Fatto" è ricevere un ordine, addebitare con successo e evaderlo lo stesso giorno usando le informazioni che hai raccolto. Se riesci a farlo per 10 ordini di fila senza correzioni manuali, hai un MVP funzionante.
Per proteggere questo obiettivo, decidi subito cosa è fuori dal perimetro. Queste funzionalità sembrano standard, ma non sono necessarie per essere pagati questa settimana: wishlist, recensioni, ricerca avanzata, regole di inventario complesse, coupon, più metodi di pagamento e più valute.
Scegli un dispositivo target per primo. Se la maggior parte degli acquirenti viene da annunci social, punta al mobile-first web. Se vendi a aziende, desktop-first può andare bene. In ogni caso, progetta per una dimensione di schermo, poi adatta.
Se stai costruendo con uno strumento chat-based come Koder.ai, scrivi lo scope prima di generare schermate e flussi. Uno scope rigoroso è il modo più semplice per evitare che "solo un'altra funzione" diventi giorno 8.
Un MVP e-commerce è “reale” quando uno sconosciuto può trovare un prodotto, pagare e tu puoi evadere l'ordine senza scambi di email.
Inizia dai prodotti. Ti servono titolo, prezzo, un'immagine principale, una breve descrizione e un interruttore attivo/disattivo così puoi nascondere gli articoli senza cancellarli. Salva varianti, bundle e prezzi complessi più tardi.
Il catalogo può restare semplice: una pagina lista prodotti e una pagina dettaglio prodotto. Filtri di base (categoria, disponibile) vanno bene, ma non costruire un motore di ricerca completo nella settimana uno.
Carrello e checkout devono essere noiosi e prevedibili. Il carrello deve supportare aggiungi, rimuovi, modifica quantità e mostrare un subtotale chiaro. Per spedizioni e tasse, scegli una regola semplice all'inizio (per esempio, spedizione fissa e tasse solo se necessario).
Un flusso end-to-end minimo di solito richiede:
L'admin è dove gli MVP spesso falliscono. Non servono grafici. Ti serve un login protetto, un modo per aggiungere/modificare prodotti e una lista ordini dove puoi cambiare lo stato (new, paid, shipped, refunded).
Esempio: vendi tre candele. Ognuna ha una foto e un prezzo. Un compratore aggiunge due pezzi, vede una spedizione fissa di $5, inserisce l'indirizzo, paga, poi tu segnali l'ordine come spedito dopo aver stampato l'etichetta.
Se usi una piattaforma vibe-coding come Koder.ai, mantieni il prompt rigoroso: "Solo queste pagine, solo questi campi, niente account, niente coupon, niente wishlist."
I pagamenti sono il posto dove evitare creatività. Scegli un provider che puoi onboardare rapidamente e lancia solo pagamenti con carta. Portafogli digitali, buy-now-pay-later e bonifici possono aspettare.
La scelta più grande è il flusso di pagamento:
Tratta i pagamenti come un piccolo insieme di stati che puoi comprendere a colpo d'occhio: created, paid, failed, canceled, refunded.
Salva solo quello che ti serve per riconciliazione e supporto: l'ID di pagamento del provider, opzionalmente l'ID cliente/sessione del provider, importo, valuta e il tuo ID ordine interno. Non memorizzare mai i dati raw della carta e non inventare campi di pagamento a meno che non siano davvero necessari.
I webhook rendono gli ordini affidabili. Dopo il checkout, non dare per scontato che un redirect del browser significhi "pagato." Aggiungi un handler di webhook che verifichi l'evento, poi segni l'ordine corrispondente come pagato.
Rendilo sicuro ai retry. I webhook verranno consegnati più di una volta, quindi il tuo handler dovrebbe essere idempotente: se un ordine è già pagato, non deve fare nulla e deve comunque restituire successo.
Se stai costruendo velocemente con un generatore chat-driven come Koder.ai, definisci prima gli stati di pagamento e i campi minimi, poi genera l'endpoint webhook e la logica di aggiornamento ordine. Questa chiarezza previene il classico disastro: clienti pagati, ordini non pagati e ore di controllo manuale.
Giorno 1: definisci lo scope. Scrivi una specifica di una pagina: cosa può fare un compratore, cosa può fare un admin e cosa è fuori dal perimetro. Scegli un provider di pagamento. Decidi come calcolerai i totali (tasse/spedizione ora o dopo). Schizza cinque schermate chiave: catalogo, pagina prodotto, carrello, checkout, risultato pagamento.
Giorno 2: pubblica il catalogo. Memorizza prodotti con solo i campi necessari: nome, prezzo, valuta, foto, breve descrizione, flag attivo. Costruisci una pagina "tutti i prodotti" (o semplici categorie) e una pagina dettaglio prodotto. Inserisci circa 10 prodotti di test per provare i flussi reali.
Giorno 3: carrello e bozze ordine. Implementa aggiungi/rimuovi e modifica quantità. Quando parte il checkout, crea una bozza d'ordine e fai uno snapshot dei prezzi così eventuali modifiche future ai prodotti non alterano gli ordini vecchi. Cattura email cliente e indirizzo di spedizione subito.
Giorno 4: pagamenti in modalità test. Collega il checkout alla creazione del pagamento. Gestisci success, canceled e failed. Salva lo stato del pagamento sull'ordine. Mostra una pagina di conferma chiara con numero d'ordine e passi successivi.
Giorno 5: admin base per l'evasione. Mantieni l'admin piccolo: crea/modifica/disabilita prodotti, una lista ordini con aggiornamenti di stato (paid, packed, shipped, refunded) e una semplice pagina "visualizza ordine" con ciò che serve per spedire.
Giorno 6: deployment e sicurezza. Configura ambienti separati di staging e production, attiva i log e prova tutto il flusso con carte di test. Scrivi un piano di rollback prima che ti serva.
Giorno 7: vai live (in piccolo e controllato). Fai un'ultima prova con un acquisto reale di basso valore, conferma email/riconferme, poi apri il negozio a un pubblico ridotto. Se usi Koder.ai, fai uno snapshot prima di ogni cambiamento importante così puoi tornare indietro velocemente se il checkout si rompe.
Un negozio della settimana uno vive o muore sulla chiarezza degli ordini. Dopo che qualcuno paga, dovresti poter rispondere rapidamente: cosa ha comprato, dove va spedito e qual è lo stato corrente?
Inizia con un modello dati piccolo e noioso. Queste cinque entità coprono quasi tutto:
Mantieni gli indirizzi minimi per velocizzare il checkout. Di solito servono solo nome, linea indirizzo 1, città, CAP e paese. Il telefono può essere opzionale a meno che il corriere non lo richieda.
Registra i totali come snapshot al momento dell'acquisto. Non ricalcolare i totali più tardi dalla tabella Product. I prezzi cambiano, le tariffe di spedizione vengono modificate e ti troverai con "il cliente ha pagato X ma l'ordine ora dice Y." Memorizza prezzo unitario per articolo, più subtotale ordine, spedizione, tasse (anche se zero) e totale finale.
Usa stati chiari che corrispondano all'evasione, non al gergo del provider di pagamento: new, paid, packed, shipped, canceled. Aggiungi refunded solo quando la supporti davvero.
Pianifica l'idempotenza negli aggiornamenti di pagamento. Lo stesso webhook può arrivare due volte o fuori ordine. Salva un ID evento univoco dal provider e ignora i duplicati.
Esempio: un webhook segna il pagamento "succeeded" due volte. Il tuo sistema non dovrebbe creare due spedizioni o inviare due email di conferma. Se stai costruendo su Koder.ai con backend Go e PostgreSQL, una constraint unica su (provider, raw_event_id) più una transazione attorno all'aggiornamento di stato è spesso sufficiente.
L'admin non è una "dashboard." È una piccola stanza dietro dove rispondi a tre domande in fretta: cosa è in vendita, cosa è stato pagato e cosa va spedito.
Inizia con un singolo login admin. Un ruolo è sufficiente. Usa una password forte, rate limiting di base e un timeout sessione breve. Salta la gestione dello staff e i permessi questa settimana. Se ti serve una seconda persona, condividi l'accesso intenzionalmente e ruotate la password dopo.
Mantieni la gestione prodotti semplice: crea/modifica prodotti, carica un'immagine principale, imposta il prezzo, attiva/disattiva disponibilità. Per l'inventario, non costruire contatori a meno che non li abbia davvero. Un interruttore in-stock/out-of-stock di solito previene overselling.
La vista ordini dovrebbe leggere come una bolla di imballaggio. Rendila facile da cercare per ID ordine o email cliente, poi mostra:
Per le azioni di stato, limitati a due pulsanti: "Mark packed" e "Mark shipped". Quando segni come spedito, opzionalmente memorizza una nota di tracking (corriere + codice tracking, o "Ritiro locale organizzato"). Le email automatiche possono aspettare se rallentano il processo.
L'export CSV è opzionale. Aggiungilo solo se sai che lo userai nella settimana uno.
Se usi uno strumento come Koder.ai, tieni l'admin nella stessa app, ma dietro una route protetta e richiedi una sessione valida.
Inizia in modalità test. Il tuo obiettivo non è “una pagina di checkout.” È un ordine che sia pagato, registrato e pronto per essere evaso.
Fai una regola ferma: non salvare mai i dettagli raw della carta sul tuo server. Usa hosted checkout o tokenizzazione client-side così i dati sensibili vanno direttamente al provider.
Logga gli errori di pagamento con il contesto su cui puoi agire: order ID, session ID, email cliente (se disponibile), totale atteso, codice errore del provider e un breve messaggio come "Amount mismatch" o "Webhook signature invalid".
Esempio: un cliente prova a comprare due mug. Il server calcola $24 + spedizione, crea la sessione e registra un ordine pending. Se il cliente chiude la pagina, l'ordine diventa canceled. Se paga, il webhook lo marca come paid e puoi evaderlo con fiducia.
Quando hai solo una settimana, i deploy possono diventare silenziosamente ciò che rompe il checkout. L'obiettivo non è DevOps sofisticato. È una routine ripetibile che riduce le sorprese e ti dà un'ancora di salvezza.
Configura due ambienti: staging e production. Lo staging dovrebbe essere il più simile possibile alla produzione: stesse impostazioni, stessi template, stesse regole tasse/spedizione, ma pagamenti in modalità test. Fai i controlli finali in staging, poi promuovi lo stesso build in produzione.
Usa release versionate. Anche se è solo v1, v2, v3, tagga ogni release e tieni pronto il precedente. Il rollback dovrebbe essere un'azione: torna al build precedente o ripristina uno snapshot. Se la tua piattaforma supporta snapshot e rollback (Koder.ai lo fa), abitualo a fare uno snapshot prima di ogni release.
Tratta le migration del database come rischiose durante la settimana MVP. Preferisci cambi compatibili all'indietro: aggiungi tabelle o colonne, non rinominare o cancellare ancora, e mantieni i vecchi percorsi funzionanti finché la nuova release non è stabile. Se devi backfillare dati, fallo in un job separato, non dentro una richiesta.
Tieni i segreti fuori dal repo. Usa variabili d'ambiente o un secret manager per API key, webhook signing secret, URL del DB e password admin.
Checklist di rilascio:
Il modo più veloce per fallire l'obiettivo dei 7 giorni è costruire funzionalità “belle” che rompono silenziosamente il flusso del denaro. Lo scopo è un negozio che prende pagamento, crea un ordine affidabile e ti permette di evaderlo.
Un errore comune è far decidere al browser il prezzo finale. Se totali, sconti o spedizioni sono calcolati client-side, prima o poi qualcuno pagherà l'importo sbagliato. Fai del server la singola fonte di verità: ricostruisci l'ordine da product ID e quantità, poi ricalcola i totali prima di creare il pagamento.
Le regole di spedizione e tasse sono un altro sink di tempo. I team perdono giorni cercando di supportare ogni paese e caso limite. Per la prima settimana, scegli una regola semplice e mantienila.
I pagamenti possono anche “funzionare” in checkout ma fallire nelle operazioni se mancano i webhook. Un cliente paga, ma il tuo DB non marca l'ordine come pagato, quindi l'evasione si blocca. Tratta la gestione dei webhook come obbligatoria.
Cinque trappole da evitare:
Esempio: un cliente completa il pagamento, poi chiude la scheda prima che si carichi la pagina di successo. Senza webhook, pensa che sia fallito, prova di nuovo e potresti ritrovarti con addebiti duplicati.
Se stai costruendo con Koder.ai, usa snapshot e rollback come parte della routine: rilascia piccoli cambiamenti, tieni una versione funzionante e recupera rapidamente se qualcosa si rompe.
Fai questi controlli prima in staging, poi ripetili subito prima di passare a live. L'obiettivo è semplice: un cliente paga una sola volta, tu lo registri una sola volta e puoi evaderlo.
Inizia dal percorso acquirente. Aggiungi un prodotto al carrello, completa il checkout e assicurati di atterrare su una pagina di successo chiara. Conferma di vedere l'ordine pagato in admin con i totali corretti.
Poi testa i webhook nella maniera difficile: ritardi e retry. I webhook possono arrivare in ritardo, arrivare due volte o fuori ordine. La tua logica di aggiornamento ordine deve essere idempotente così i retry non creano ordini pagati duplicati.
Checklist pre-lancio:
Fai una carica live reale prima di annunciare nulla. Usa una carta reale, un importo piccolo e il tuo indirizzo di spedizione. Dovresti vedere l'ordine apparire esattamente una volta, con timestamp e stato chiari.
Se usi Koder.ai, esercitati con snapshot: rilascia, effettua un ordine, rollback e conferma che gli ordini esistenti si caricano correttamente.
Immagina un piccolo torrefattore che vuole vendere 12 confezioni di caffè online. Non serve subscription, recensioni o programma fedeltà. Serve un negozio semplice che prenda soldi veri e crei ordini puliti da evadere.
Al giorno 2, il catalogo è sufficiente se ogni prodotto ha una foto chiara, un prezzo e una breve descrizione (livello di tostatura, note di degustazione, dimensione busta). Mantieni opzioni minime: una sola taglia per prodotto e un'opzione di spedizione (per esempio, tariffa fissa in un paese).
Al giorno 4, il checkout fa un lavoro: raccogliere dati di spedizione, prendere il pagamento con carta e mostrare una pagina di conferma che il cliente può screenshotare. Mostra un ID ordine e un breve riepilogo (articoli, totale, indirizzo di spedizione). Se un cliente scrive al supporto, quell'ID ordine è il modo più veloce per capire cosa è successo.
Al giorno 5, l'admin resta intenzionalmente semplice. Il torrefattore effettua il login, vede nuovi ordini e sposta gli ordini attraverso paid, packed, shipped. Il tracking può arrivare dopo. Nella settimana uno, una nota tipo "Spedito tramite servizio postale, etichetta stampata alle 15:10" è spesso sufficiente.
Questo è anche il tipo di perimetro che funziona bene con builder chat-first come Koder.ai: poche schermate, poche tabelle e un workflow chiaro.
Settimana 2: idee da aspettare: codici sconto, ricerca migliorata, conteggi di inventario e email più automatiche. Aggiungile solo dopo che gli ordini reali ti dicono cosa conta.
Tratta la prima settimana live come uno sprint di apprendimento. Fai passare ordini reali nel sistema, poi rimuovi l'attrito più grande che puoi dimostrare.
Inizia con un piccolo pilot: punta a 10 ordini pagati da amici, colleghi o un pubblico ristretto che puoi contattare direttamente. Chiedi a ciascuno dove hanno esitato. Traccia gli abbandoni in un foglio semplice: pagina prodotto -> carrello -> checkout iniziato -> pagamento riuscito.
Dopo il pilot, aggiungi una sola modifica per volta. I migliori upgrade iniziali sono di solito semplici: costi di spedizione più chiari, foto prodotto migliori, meno campi al checkout. Scegli il prossimo ostacolo più grande dalle tue note, correggilo e fai un'altra piccola tornata.
Il supporto clienti ti mostrerà anche cosa manca velocemente. Salva risposte brevi per le domande ricorrenti: dov'è il mio ordine, posso cancellare, perché il pagamento è fallito, quanto costa la spedizione e quando arriva, posso cambiare l'indirizzo.
Se vuoi iterare velocemente senza rischiare il checkout, Koder.ai può aiutarti a generare la versione successiva da chat e usare snapshot e rollback così puoi testare i cambiamenti in sicurezza prima di pubblicarli.
Un MVP “reale” è quello in cui uno sconosciuto può pagare con successo, voi potete vedere un ordine pagato con i totali e i dati di spedizione corretti, e potete evaderlo lo stesso giorno senza dover indovinare.
Se riuscite a processare 10 ordini di fila senza interventi manuali, siete in una buona posizione.
Scegliete un paese, una valuta e un metodo di pagamento (di solito carte). Limitate spedizione e tasse a una regola semplice (per esempio spedizione a tariffa fissa e tasse = 0 se possibile).
Il perimetro resta piccolo quando ogni decisione supporta: prodotto → carrello → checkout → ordine pagato → evasione.
Iniziate con:
Evitate account, wishlist, recensioni, coupon, più valute e più metodi di pagamento per la prima settimana.
Il hosted checkout è solitamente la scelta predefinita per un MVP di 7 giorni perché è più veloce e riduce problemi di sicurezza e UI.
I form di carta embedded possono sembrare più “nativi”, ma spesso introducono più casi limite e lavoro aggiuntivo per la sicurezza.
Usate il webhook come fonte di verità. Le pagine di redirect sono utili per l'esperienza utente, ma non sono affidabili (schede chiuse, errori di rete).
Utilizzate il webhook per segnare l'ordine come pagato solo dopo aver verificato l'evento e aver confrontato importo e valuta attesi.
Usate un handler di webhook idempotente:
Così evitate doppie email, doppie spedizioni e scenari confusi di "pagato due volte".
Salvate snapshot al momento dell'acquisto:
Non ricalcolate i totali in seguito dalla tabella Product, perché prezzi e regole cambiano e otterrete record incoerenti.
Mantenete gli stati semplici e focalizzati sull'evasione:
L'admin deve rispondere a tre domande rapidamente: cosa è in vendita, cosa è stato pagato e cosa deve essere spedito.
Funzionalità minime:
Evitate grafici e ruoli complessi nella prima settimana.
Una routine semplice e sicura:
Se usate Koder.ai, fate uno prima di ogni modifica importante per poter tornare indietro velocemente se il checkout si rompe.
new, paid, packed, shipped, canceled (aggiungete refunded solo se supportate davvero i rimborsi)created, paid, failed, canceled, refundedL'obiettivo è poter vedere a colpo d'occhio cosa fare dopo.