MVP e-commerce w 7 dni: plan dzień po dniu, by uruchomić mały sklep z katalogiem, checkoutem, prawdziwymi płatnościami, podstawowym panelem admina i bezpiecznymi wydaniami.
created, paid, failed, canceled, refunded.\n\nPrzechowuj tylko to, co potrzebne do rozliczeń i wsparcia: provider payment ID, opcjonalne provider customer/session ID, kwota, waluta i Twój wewnętrzny order ID. Nigdy nie zapisuj surowych danych karty i nie wymyślaj własnych pól płatności, jeśli naprawdę ich nie potrzebujesz.\n\nWebhooki czynią zamówienia niezawodnymi. Po checkout nie zakładaj, że przekierowanie w przeglądarce oznacza „paid”. Dodaj handler webhooka, który weryfikuje zdarzenie, a potem oznacza dopasowane zamówienie jako opłacone.\n\nZadbaj o bezpieczeństwo przy ponownych dostawach zdarzeń. Webhooki będą dostarczane wielokrotnie, więc Twój handler powinien być idempotentny: jeśli zamówienie jest już opłacone, nie powinien nic robić i nadal zwrócić sukces.\n\nJeśli budujesz szybko z narzędziem czatowym jak Koder.ai, zdefiniuj najpierw stany płatności i minimalne pola, potem wygeneruj endpoint webhooka i logikę aktualizacji zamówienia. Ta jasność zapobiega klasycznemu bałaganowi: klienci zapłacili, zamówienia nieopłacone, godziny ręcznego sprawdzania.\n\n## Plan dzień po dniu na 7-dniową budowę\n\nDzień 1: zamknij zakres. Napisz jednostronicową specyfikację: co może zrobić kupujący, co admin, i co jest poza zakresem. Wybierz dostawcę płatności. Zdecyduj, jak policzysz sumy (podatki/wysyłka teraz, czy później). Naszkicuj pięć kluczowych ekranów: katalog, strona produktu, koszyk, checkout, wynik płatności.\n\nDzień 2: wypuść katalog. Zapisuj produkty tylko z potrzebnymi polami: nazwa, cena, waluta, zdjęcie, krótki opis, flaga aktywne. Zbuduj stronę „wszystkie produkty” (lub proste kategorie) i stronę szczegółów produktu. Zasiej ok. 10 testowych produktów, by móc testować prawdziwe flow.\n\nDzień 3: koszyk i szkice zamówień. Zaimplementuj dodawanie/usuwanie i zmianę ilości. Kiedy zaczyna się checkout, utwórz szkic zamówienia i zrób snapshot cen, żeby późniejsze edycje produktów nie zmieniały starych zamówień. Złap email klienta i adres wysyłki możliwie wcześnie.\n\nDzień 4: płatności w trybie testowym. Podłącz checkout do tworzenia płatności. Obsłuż success, canceled i failed. Zapisz status płatności w zamówieniu. Pokaż wyraźną stronę potwierdzenia z numerem zamówienia i kolejnymi krokami.\n\nDzień 5: podstawowy admin do realizacji. Trzymaj admin mały: tworzenie/edycja/wyłączenie produktów, lista zamówień z aktualizacją statusów (paid, packed, shipped, refunded) i prosta strona „pokaż zamówienie” z tym, co potrzebujesz do wysyłki.\n\nDzień 6: wdrożenie i zabezpieczenia. Skonfiguruj oddzielne środowiska staging i production, włącz logi i przećwicz cały flow z kartami testowymi. Napisz plan rollback zanim będzie potrzebny.\n\nDzień 7: uruchomienie (małe, kontrolowane). Zrób finalny przegląd z rzeczywistym, niskokwotowym zakupem, potwierdź maile/rachunki, potem otwórz sklep dla małej grupy odbiorców. Jeśli używasz Koder.ai, rób snapshot przed każdą większą zmianą, aby szybko cofnąć, jeśli checkout przestanie działać.\n\n## Dane, które musisz przechowywać, żeby uniknąć bałaganu\n\nSklep z tygodnia życia zależy od jasności zamówień. Gdy ktoś zapłaci, powinieneś szybko odpowiedzieć: co kupił, gdzie wysyłamy i jaki jest aktualny status?\n\nZacznij od małego, nudnego modelu danych. Te pięć rekordów pokrywa prawie wszystko:\n\n- Product: id, title, price, currency, active\n- Customer: id, email, name (opcjonalnie)\n- Order: id, customer_id (lub email), pola adresu wysyłki, status, snapshot sum, created_at\n- OrderItem: order_id, product_id, title_snapshot, unit_price_snapshot, quantity\n- Payment: order_id, provider, provider_payment_id, amount, currency, status, raw_event_id\n\nTrzymaj adresy minimalistycznie, żeby checkout był szybki. Zwykle wystarczy: imię, linia1 adresu, miasto, kod pocztowy i kraj. Telefon opcjonalny, chyba że wymaga go przewoźnik.\n\nZapisuj sumy jako snapshot w momencie zakupu. Nie przeliczaj później z tabeli Product. Ceny się zmieniają, stawki wysyłki się poprawiają i skończysz z „klient zapłacił X, ale zamówienie teraz mówi Y”. Przechowuj cenę jednostkową za pozycję oraz subtotal, wysyłkę, podatek (nawet zero) i sumę końcową.\n\nUżywaj jasnych statusów, które odzwierciedlają realizację, a nie żargon dostawcy płatności: new, paid, packed, shipped, canceled. Dodaj refunded tylko wtedy, gdy naprawdę to obsługujesz.\n\nPlanuj idempotencję w aktualizacjach płatności. To samo zdarzenie webhook może przyjść dwukrotnie lub w nieodpowiedniej kolejności. Zapisz unikalne event ID od dostawcy i ignoruj duplikaty.\n\nPrzykład: webhook oznacza płatność jako „succeeded” dwukrotnie. Twoje system powinien nie tworzyć dwóch wysyłek ani wysyłać dwóch maili potwierdzających. Jeśli budujesz na Koder.ai z backendem w Go i PostgreSQL, unikalne ograniczenie na (provider, raw_event_id) plus transakcja wokół aktualizacji statusu często wystarczą.\n\n## Podstawowy admin: tylko to, co pomaga realizować zamówienia\n\nAdmin to nie „dashboard”. To małe zaplecze, w którym szybko odpowiadasz na trzy pytania: co jest na sprzedaż, co zostało opłacone i co trzeba wysłać.\n\nZacznij od jednego konta admina. Jedna rola wystarczy. Użyj silnego hasła, podstawowego rate limiting i krótkiego czasu sesji. Pomijaj zarządzanie personelem i uprawnienia w tym tygodniu. Jeśli potrzebujesz drugiej osoby, udostępnij dostęp celowo i rotuj hasło później.\n\nUtrzymaj zarządzanie produktami proste: tworzenie/edycja produktów, przesłanie jednego głównego zdjęcia, ustawienie ceny, przełącznik dostępności. Dla zapasów nie buduj liczników chyba, że naprawdę je masz. Przełącznik dostępne/niedostępne zwykle wystarcza, by uniknąć oversellingu.\n\nWidok zamówień powinien wyglądać jak lista do pakowania. Ułatw wyszukiwanie po ID zamówienia lub emailu klienta, a potem pokaż:\n\n- Imię klienta, email, adres wysyłki\n- Pozycje, ilości i finalne sumy (włącznie z wysyłką i podatkiem)\n- Status płatności (paid, failed, refunded)\n- Status realizacji (new, packed, shipped)\n- Timestamps i krótka notatka wewnętrzna\n\nDla akcji statusu ogranicz się do dwóch przycisków: „Mark packed” i „Mark shipped”. Przy oznaczaniu jako wysłane opcjonalnie zapisz notatkę śledzenia (przewoźnik + numer przesyłki, albo „Odbiór osobisty uzgodniony”). Automatyczne maile mogą poczekać, jeśli spowalniają pracę.\n\nEksport CSV jest opcjonalny. Dodaj go tylko jeśli wiesz, że będziesz go używać w pierwszym tygodniu.\n\nJeśli używasz narzędzia typu Koder.ai, trzymaj admin w tej samej aplikacji, ale zabezpiecz trasę i wymagaj ważnej sesji.\n\n## Krok po kroku: osiągnij pierwszą pomyślną płatność\n\nZacznij w trybie testowym. Twoim celem nie jest „strona checkout”. Twoim celem jest jedno zamówienie, które jest zapłacone, zapisane i gotowe do realizacji.\n\nUstal jedną twardą zasadę: nigdy nie zapisuj surowych danych karty na swoim serwerze. Użyj hosted checkout albo tokenizacji po stronie klienta, żeby wrażliwe dane trafiały prosto do dostawcy płatności.\n\n### Droga do pierwszego opłaconego zamówienia\n\n1. Utwórz testowy produkt i jego cenę na serwerze. Checkout musi pobierać ceny z bazy, nie z przeglądarki.\n2. Rozpocznij sesję checkout w trybie testowym. Backend tworzy sesję płatności i zwraca tylko to, czego klient potrzebuje do przekierowania.\n3. Chroń przed podwójnymi kliknięciami. Wyłącz przycisk Pay po pierwszym kliknięciu. Użyj po stronie serwera idempotency key (np. ID koszyka + krótki przedział czasu), żeby duplikaty zwracały tę samą sesję zamiast tworzyć drugie obciążenie.\n4. Weryfikuj płatność po stronie serwera. Traktuj webhook dostawcy jako źródło prawdy. Oznacz zamówienie jako opłacone dopiero po potwierdzeniu, że zdarzenie jest prawdziwe i pasuje kwotą oraz walutą.\n5. Testuj ścieżki błędów. Uruchom płatność nieudaną, anulowaną i wygasłą sesję. Każda powinna kończyć się jasnym stanem zamówienia, a nie tajemnicą.\n\n### Ułatwianie naprawy błędów\n\nLoguj błędy płatności z kontekstem, na którym możesz działać: order ID, session ID, email klienta (jeśli dostępny), oczekiwana suma, kod błędu dostawcy i krótka wiadomość jak „Amount mismatch” lub „Webhook signature invalid”.\n\nPrzykład: klient próbuje kupić dwa kubki. Twój serwer liczy 24$ + wysyłka, tworzy sesję i zapisuje zamówienie jako pending. Jeśli klient zamknie stronę, zamówienie staje się canceled. Jeśli zapłaci, webhook zmienia je na paid i możesz je pewnie zrealizować.\n\n## Bezpieczny workflow wdrożeniowy, którego naprawdę będziesz przestrzegać\n\nGdy masz tylko tydzień, wdrożenia mogą cicho stać się tym, co psuje checkout. Cel to nie finezyjne DevOps. To powtarzalna procedura, która redukuje niespodzianki i daje wyjście awaryjne.\n\nSkonfiguruj dwa środowiska: staging i production. Staging powinien być jak najbliżej produkcji: te same ustawienia, te same szablony, te same reguły podatkowe/wysyłkowe, ale płatności w trybie testowym. Sprawdź wszystko na staging, potem wypromuj dokładnie tę samą kompilację na produkcję.\n\nUżywaj wersjonowanych wydań. Nawet jeśli to tylko v1, v2, v3 — taguj każde wydanie i trzymaj poprzednie gotowe. Rollback powinien być jedną akcją: przełącz na poprzednią kompilację lub przywróć snapshot. Jeśli platforma wspiera snapshoty i rollback (Koder.ai to robi), rób to zanim wprowadzisz zmiany produkcyjne.\n\nTraktuj migracje bazy jako ryzykowne w tygodniu MVP. Preferuj zmiany kompatybilne wstecz: dodawaj nowe tabele lub kolumny, nie zmieniaj nazw ani nie usuwaj, i trzymaj stare ścieżki kodu działające, aż nowa wersja będzie stabilna. Jeśli musisz uzupełnić dane, zrób to w osobnym zadaniu, nie w żądaniu użytkownika.\n\nTrzymaj sekrety poza repozytorium. Używaj zmiennych środowiskowych lub menedżera sekretów dla kluczy API, sekretów webhooków, URLi bazy i haseł admina.\n\nChecklista przed wydaniem:\n\n- Potwierdź, że staging checkout działa end-to-end z kartą testową i zdarzeniem webhook\n- Uruchom migracje na staging, potem na produkcji, i potwierdź, że tworzenie zamówień nadal działa\n- Zweryfikuj maile (potwierdzenie zamówienia, błąd płatności) i ich wygląd\n- Zrób snapshot przed wydaniem i zanotuj wersję\n- Szybki przegląd: jedna osoba wdraża, inna sprawdza listę\n\n## Typowe pułapki, które spowalniają 7-dniowe MVP\n\nNajszybszy sposób, żeby nie zdążyć w 7 dni, to budować „fajne” funkcje, które po cichu psują przepływ pieniędzy. Punkt to sklep, który przyjmuje płatność, tworzy wiarygodne zamówienie i pozwala je zrealizować.\n\nCzęsty błąd to pozwolić przeglądarce decydować o ostatecznej cenie. Jeśli sumy, rabaty czy wysyłka są liczone po stronie klienta, ktoś prędzej czy później zapłaci niewłaściwą kwotę. Niech serwer będzie jedynym źródłem prawdy: odbuduj zamówienie z ID produktów i ilości, potem przelicz sumy przed utworzeniem płatności.\n\nReguły wysyłki i podatków to kolejna strata czasu. Zespoły tracą dni próbując obsłużyć każdy kraj i przypadek brzegowy. Na tydzień jeden wybierz prostą regułę i trzymaj się jej.\n\nPłatności mogą także „działać” na stronie, ale zawieść w operacjach, jeśli webhooki brakują. Klient płaci, ale twoja baza nie oznacza zamówienia jako opłacone, więc realizacja stoi. Traktuj obsługę webhooków jako obowiązkową.\n\nPięć pułapek do pilnowania:\n\n- Zaufanie klient-side totals zamiast przeliczania na serwerze\n- Budowanie złożonych tabel wysyłki i podatków zanim pojawi się popyt\n- Pomijanie webhooków i poleganie tylko na stronach przekierowań\n- Brak jasnego komunikatu potwierdzającego zamówienie lub maila\n- Wdrażanie prosto na produkcję bez możliwości rollbacku\n\nPrzykład: klient kończy płatność, zamyka kartę przed załadowaniem strony sukcesu. Bez webhooków zakłada, że płatność nie powiodła się i próbuje ponownie — możesz skończyć z podwójnymi obciążeniami.\n\nJeśli budujesz z Koder.ai, używaj snapshotów i rollbacku jako rutyny: wypuszczaj małe zmiany, trzymaj znaną dobrą wersję i szybko odzyskuj, jeśli coś się zepsuje.\n\n## Szybkie kontrole przed włączeniem płatności na żywo\n\nZrób te kontrole najpierw na stagingu, potem powtórz tuż przed przełączeniem na live. Cel jest prosty: jeden klient płaci raz, zapisujesz to raz i możesz zrealizować zamówienie.\n\nZacznij od ścieżki kupującego. Dodaj produkt do koszyka, dokończ checkout i upewnij się, że trafiasz na jasną stronę sukcesu. Potwierdź, że widzisz opłacone zamówienie w adminie z poprawnymi sumami.\n\nPotem testuj webhooki „na ciężko”: opóźnienia i ponowne dostawy. Webhooki mogą przyjść późno, dwukrotnie lub w złej kolejności. Logika aktualizacji zamówienia powinna być idempotentna, żeby retry nigdy nie tworzył duplikatu opłaconego zamówienia.\n\nChecklist pre-launch:\n\n- Złóż testowe zamówienie end-to-end i potwierdź, że pojawia się w adminie z zapisanym transaction/payment ID\n- Wyślij to samo zdarzenie webhook ponownie i potwierdź, że nic się nie dubluje\n- Wyłącz jeden produkt i potwierdź, że znika i nie można go kupić\n- W adminie przesuń zamówienie przez statusy (new -> paid -> shipped) i dodaj notatkę wewnętrzną\n- Wdróż małą zmianę i przywróć ją w kilka minut bez utraty danych zamówień\n\nZrób jedno realne, niskokwotowe obciążenie zanim cokolwiek ogłosisz. Użyj prawdziwej karty, niewielkiej kwoty i własnego adresu wysyłki. Powinieneś zobaczyć zamówienie dokładnie raz, z jasnym timestampem i statusem.\n\nJeśli używasz Koder.ai, poćwicz to ze snapshotami: wdrożenie, złożenie zamówienia, rollback i potwierdzenie, że istniejące zamówienia wciąż się poprawnie ładują.\n\n## Przykładowy scenariusz: mały sklep, który możesz wysłać w tym tygodniu\n\nWyobraź sobie małą palarnię kawy, która chce sprzedać 12 opakowań kawy online. Nie potrzebują subskrypcji, recenzji ani programu lojalnościowego. Potrzebują prostego sklepu, który przyjmuje prawdziwe pieniądze i tworzy czytelne zamówienia do realizacji.\n\nDo dnia 2 katalog jest wystarczający, jeśli każdy produkt ma wyraźne zdjęcie, cenę i krótki opis (stopień palenia, nuty smakowe, rozmiar opakowania). Trzymaj opcje minimalne: jeden rozmiar na produkt i jedna opcja wysyłki (np. stawka stała w jednym kraju).\n\nDo dnia 4 checkout robi jedno zadanie: zbiera dane wysyłkowe, pobiera płatność kartą i pokazuje stronę potwierdzenia, którą klient może screenshotować. Wyświetl ID zamówienia i krótkie podsumowanie (pozycje, suma, adres wysyłki). Jeśli klient napisze do supportu, to ID zamówienia najszybciej pokaże, co się stało.\n\nDo dnia 5 admin pozostaje celowo prosty. Palarnia loguje się, widzi nowe zamówienia i przesuwa je przez paid, packed, shipped. Śledzenie może przyjść później. W pierwszym tygodniu notatka typu „Wysłano pocztą, etykieta wydrukowana o 15:10” często wystarczy.\n\nTo też zakres, który dobrze pasuje do narzędzi chat-first jak Koder.ai: kilka ekranów, kilka tabel i klarowny workflow.\n\nTydzień 2: pomysły warte czekania: kody rabatowe, lepsze wyszukiwanie, liczniki magazynowe i bardziej automatyczne maile. Dodawaj je dopiero po tym, jak realne zamówienia pokażą, co się opłaca.MVP „na serio” to taki, w którym obca osoba może pomyślnie zapłacić, Ty możesz zobaczyć opłacone zamówienie z poprawnymi kwotami i danymi wysyłkowymi, i możesz je zrealizować tego samego dnia bez zgadywania.
Jeśli potrafisz przeprowadzić 10 zamówień pod rząd bez ręcznych poprawek, jesteś w bardzo dobrym miejscu.
Wybierz jeden kraj, jedną walutę i jedną metodę płatności (zwykle karty). Utrzymaj wysyłkę i podatek do jednej prostej zasady (np. stała opłata za wysyłkę i brak podatku, jeśli to możliwe).
Zakres pozostaje mały, gdy każda decyzja wspiera: produkt → koszyk → checkout → opłacone zamówienie → realizacja.
Zacznij od:
Pomiń konta użytkowników, wishlisty, opinie, kupony, wiele walut i wiele metod płatności.
Hosted checkout to zwykle domyślne rozwiązanie na 7-dniowe MVP — jest szybsze i zmniejsza problemy z bezpieczeństwem i UI.
Formularze osadzone wyglądają bardziej „native”, ale zwykle wprowadzają więcej przypadków brzegowych i wymagają więcej pracy, by bezpiecznie je obsłużyć.
Traktuj webhook jako źródło prawdy. Strony przekierowań poprawiają UX, ale nie są niezawodne (karty zamykane, problemy sieciowe).
Użyj webhooka, by oznaczyć zamówienie jako opłacone dopiero po zweryfikowaniu zdarzenia i dopasowaniu oczekiwanej kwoty/waluty.
Zaimplementuj idempotentny handler webhooków:
To zapobiega podwójnym mailom, podwójnym wysyłkom i zamieszaniu „opłacone dwukrotnie”.
Zapisuj snapshoty w momencie zakupu:
Nie przeliczaj później sum z tabeli Product, bo ceny i zasady się zmieniają i otrzymasz niespójne zapisy.
Utrzymuj statusy proste i skupione na realizacji:
Admin ma odpowiadać krótko na trzy pytania: co jest na sprzedaż, co zostało opłacone i co trzeba wysłać.
Minimalne funkcje admina:
Pomiń wykresy i skomplikowane role w pierwszym tygodniu.
Prosta, bezpieczna rutyna:
Jeśli używasz Koder.ai, rób przed każdym większym krokiem, aby szybko przywrócić sprawną wersję, jeśli checkout przestanie działać.
new, paid, packed, shipped, canceled (dodaj refunded tylko jeśli faktycznie wspierasz zwroty)created, paid, failed, canceled, refundedCel: jednym rzutem oka wiedzieć, co robić dalej.