Ecommerce MVP in 7 days: ship a tiny store with real payments

What you are shipping (and what you are not)

For an ecommerce MVP you can finish in a week, “real payments” means one thing: a real customer can pay, you can see the order, and you can ship it without guessing.

Keep the first version narrow: one country, one currency, and one payment method (usually cards). If you try to support everything, you’ll spend the week on edge cases instead of selling.

The shortest path is a tiny store that does only the steps needed to move money and trigger fulfillment:

• A product page with a clear price and stock status
• A cart that can change quantity and show totals
• A checkout that collects name, email, and shipping address
• A confirmation page (plus an email receipt if you can)

“Done” isn’t a perfect storefront. “Done” is taking an order, charging successfully, and fulfilling it the same day using the info you collected. If you can do that for 10 orders in a row without manual fixes, you have a working MVP.

To protect that goal, decide upfront what is out of scope. These features feel standard, but they’re not required to get paid this week: wishlists, reviews, advanced search, complex inventory rules, coupons, multiple payment methods, and multiple currencies.

Pick one device target first. If most buyers come from social ads, go mobile-first web. If you sell to businesses, desktop-first can be fine. Either way, design for one screen size first, then adjust.

If you’re building with a chat-based tool like Koder.ai, write the scope down before generating screens and flows. A strict scope is the easiest way to stop “just one more feature” from turning into day 8.

The smallest feature set that still works

An ecommerce MVP is “real” when a stranger can find a product, pay, and you can fulfill the order without a back-and-forth email.

Start with products. You need a title, a price, one main image, a short description, and an on/off switch so you can hide items without deleting them. Save variants, bundles, and complex pricing for later.

Your catalog can stay simple: a product list page and a product detail page. Basic filters (like category or in-stock) are fine, but don’t build a full search engine in week one.

Cart and checkout should be boring and predictable. The cart must support add, remove, change quantity, and show a clear subtotal. For shipping and tax, choose one simple rule at first (for example, flat shipping and tax only if you must).

A minimal end-to-end flow usually needs:

• Product list
• Product detail
• Cart
• Checkout (customer info + shipping address + summary)
• Admin area (products and orders)

Admin is where MVPs often fail. You don’t need charts. You need a locked login, a way to add/edit products, and an orders list where you can change status (new, paid, shipped, refunded).

Example: you sell three candles. Each has one photo and one price. A buyer adds two, sees a flat $5 shipping fee, enters their address, pays, then you mark the order shipped after printing the label.

If you’re using a vibe-coding platform like Koder.ai, keep the prompt strict: “Only these pages, only these fields, no accounts, no coupons, no wishlists.”

Payments: keep it real, keep it boring

Payments are the place to avoid creativity. Pick one provider you can onboard quickly and ship card payments only. Digital wallets, buy-now-pay-later, and bank transfers can wait.

The biggest choice is the payment flow:

• Hosted checkout is usually the fastest and safest, because the provider handles most sensitive UI.
• Embedded card forms can look nicer, but they add more edge cases and more security work.

Treat payments as a small set of states you can understand at a glance: created, paid, failed, canceled, refunded.

Store only what you need for reconciliation and support: the provider payment ID, optional provider customer/session ID, amount, currency, and your internal order ID. Never store raw card data, and don’t invent your own payment fields unless you truly need them.

Webhooks make orders reliable. After checkout, don’t assume a browser redirect means “paid.” Add a webhook handler that verifies the event, then marks the matching order as paid.

Make it safe under retries. Webhooks will be delivered more than once, so your handler should be idempotent: if an order is already paid, it should do nothing and still return success.

If you’re building fast with a chat-driven builder like Koder.ai, define payment states and minimal fields first, then generate the webhook endpoint and order update logic. That clarity prevents the classic mess: paid customers, unpaid orders, and hours of manual checking.

Day-by-day plan for the 7-day build

Day 1: lock the scope. Write a one-page spec: what a shopper can do, what an admin can do, and what’s out of scope. Pick a payment provider. Decide how you’ll calculate totals (tax/shipping now, or later). Sketch five key screens: catalog, product page, cart, checkout, payment result.

Day 2: ship the catalog. Store products with only the fields you need: name, price, currency, photo, short description, active flag. Build an “all products” page (or simple categories) and a product detail page. Seed around 10 test products so you can test real flows.

Day 3: cart and order drafts. Implement add/remove and quantity changes. When checkout starts, create an order draft and snapshot prices so later product edits don’t change old orders. Capture customer email and shipping address early.

Day 4: payments in test mode. Connect checkout to payment creation. Handle success, canceled, and failed payments. Save payment status on the order. Show a clear confirmation page with order number and next steps.

Day 5: basic admin for fulfillment. Keep admin small: product create/edit/disable, an orders list with status updates (paid, packed, shipped, refunded), and a simple “view order” page with what you need to ship.

Day 6: deployment and safety. Set up separate staging and production environments, turn on logs, and rehearse the whole flow with test cards. Write a rollback plan before you need it.

Day 7: go live (small, controlled). Do a final run-through with a real low-value purchase, confirm emails/receipts, then open the store to a small audience first. If you use Koder.ai, take a snapshot before each major change so you can roll back fast if checkout breaks.

Data you must store to avoid messy orders

A week-one store lives or dies on order clarity. Once someone pays, you should be able to answer quickly: what did they buy, where does it ship, and what’s the current state?

Start with a small, boring data model. These five records cover almost everything:

• Product: id, title, price, currency, active
• Customer: id, email, name (optional)
• Order: id, customer_id (or email), shipping address fields, 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

Keep addresses minimal so checkout stays quick. You usually only need name, line1, city, postal code, and country. Phone can be optional unless your carrier requires it.

Record totals as a snapshot at purchase time. Don’t recalculate totals later from the Product table. Prices change, shipping rates get tweaked, and you’ll end up with “the customer paid X but the order now says Y.” Store unit price per item, plus order subtotal, shipping, tax (even if zero), and grand total.

Use clear statuses that match fulfillment, not payment-provider jargon: new, paid, packed, shipped, canceled. Add refunded only when you truly support it.

Plan for idempotency in payment updates. The same webhook can arrive twice or out of order. Store a unique event ID from the provider and ignore duplicates.

Example: a webhook marks payment “succeeded” twice. Your system should not create two shipments or send two confirmation emails. If you’re building on Koder.ai with a Go backend and PostgreSQL, a unique constraint on (provider, raw_event_id) plus a transaction around the status update is often enough.

Basic admin: only what helps you fulfill orders

Admin isn’t a “dashboard.” It’s a small back room where you answer three questions fast: what’s for sale, what got paid, and what needs shipping.

Start with a single admin login. One role is enough. Use a strong password, basic rate limiting, and a short session timeout. Skip staff management and permissions this week. If you need a second person to help, share access intentionally and rotate the password later.

Keep product management simple: create/edit products, upload one main image, set price, toggle availability. For inventory, don’t build counts unless you truly have them. An in-stock/out-of-stock switch usually prevents overselling.

Your orders view should read like a packing slip. Make it easy to search by order ID or customer email, then show:

• Customer name, email, shipping address
• Items, quantities, and final totals (including shipping and tax)
• Payment status (paid, failed, refunded)
• Fulfillment status (new, packed, shipped)
• Timestamps and a short internal note

For status actions, keep it to two buttons: “Mark packed” and “Mark shipped.” When you mark shipped, optionally store a tracking note (carrier + tracking code, or “Local pickup arranged”). Automated emails can wait if they’re going to slow you down.

CSV export is optional. Add it only if you know you’ll use it in week one.

If you’re using a build tool like Koder.ai, keep admin in the same app, but gate it behind a protected route and require a valid session.

Step-by-step: make the first successful payment

Start in test mode. Your goal isn’t “a checkout page.” Your goal is one order that’s paid, recorded, and ready to fulfill.

Make one hard rule: never store raw card details on your server. Use hosted checkout or client-side tokenization so sensitive data goes straight to the payment provider.

The path to your first paid order

1. Create a test product and price on the server. Checkout must fetch prices from your database, not from the browser.
2. Start a checkout session in test mode. Your backend creates the payment session and returns only what the client needs to redirect.
3. Protect against double clicks. Disable the Pay button after the first click. Use a server-side idempotency key (for example, cart ID plus a short time window) so duplicates return the same session instead of creating a second charge.
4. Verify payment on the server. Treat the provider webhook as the source of truth. Mark the order paid only after you confirm the event is real and matches expected amount and currency.
5. Test failure paths. Run a failed payment, a canceled checkout, and an expired session. Each should end in a clear order state, not a mystery.

Make errors easy to fix

Log payment errors with context you can act on: order ID, session ID, customer email (if available), expected total, provider error code, and a short message like “Amount mismatch” or “Webhook signature invalid.”

Example: a customer tries to buy two mugs. Your server calculates $24 + shipping, creates the session, and records an order as pending. If the customer closes the page, the order becomes canceled. If they pay, the webhook flips it to paid and you can fulfill it confidently.

A safe deployment workflow you can actually follow

When you only have a week, deployments can quietly become the thing that breaks checkout. The goal isn’t fancy DevOps. It’s a repeatable routine that reduces surprises and gives you an escape hatch.

Set up two environments: staging and production. Staging should be as close to production as you can make it: same settings, same templates, same tax/shipping rules, but payment in test mode. Do final checks in staging, then promote the exact same build to production.

Use versioned releases. Even if it’s just v1, v2, v3, tag each release and keep the previous one ready. Rollback should be one action: switch back to the previous build or restore a snapshot. If your platform supports snapshots and rollback (Koder.ai does), make it a habit to snapshot right before every production release.

Treat database migrations as risky during MVP week. Prefer backward-compatible changes: add new tables or columns, don’t rename or delete yet, and keep old code paths working until the new release is stable. If you need to backfill data, do it in a separate job, not inside a request.

Keep secrets out of your repo. Use environment variables or a secret manager for API keys, webhook signing secrets, database URLs, and admin passwords.

Release checklist:

• Confirm staging checkout works end-to-end with a test card and a webhook event
• Run migrations on staging, then production, and confirm order creation still works
• Verify emails (order confirmation, failed payment) send and look correct
• Take a pre-release snapshot and note the release version
• Do a quick second review: one person ships, another checks the list

Common traps that slow down a 7-day MVP

The fastest way to miss a 7-day goal is to build “nice” features that quietly break the money flow. The point is a store that takes payment, creates a reliable order, and lets you fulfill it.

A common mistake is letting the browser decide the final price. If totals, discounts, or shipping are calculated on the client, someone will eventually pay the wrong amount. Make the server the single source of truth: rebuild the order from product IDs and quantities, then calculate totals again before creating a payment.

Shipping and tax rules are another time sink. Teams lose days trying to support every country and edge case. For week one, pick one simple rule and stick to it.

Payments can also “work” in checkout but fail in operations if webhooks are missing. A customer pays, but your database never marks the order paid, so fulfillment stalls. Treat webhook handling as required.

Five traps to watch for:

• Trusting client-side totals instead of recalculating on the server
• Building complex shipping and tax tables before you have demand
• Skipping webhooks and relying only on “payment succeeded” redirect pages
• Forgetting a clear order confirmation message or email
• Deploying straight to production with no rollback path

Example: a customer completes payment, then closes the tab before the success page loads. Without webhooks, they assume it failed, try again, and you may end up with duplicate charges.

If you’re building with Koder.ai, use snapshots and rollback as part of your routine: ship small changes, keep a known good version, and recover fast if something breaks.

Quick checks before you turn on live payments

Do these checks in staging first, then repeat them right before you switch to live. The goal is simple: one customer pays once, you record it once, and you can fulfill it.

Start with the buyer path. Add a product to the cart, complete checkout, and make sure you land on a clear success page. Confirm you can see the paid order in admin with the right totals.

Then test webhooks the hard way: delays and retries. Webhooks can arrive late, arrive twice, or arrive out of order. Your order update logic should be idempotent so retries never create duplicate paid orders.

Pre-launch checklist:

• Place a test order end-to-end and confirm it appears in admin with the transaction/payment ID saved
• Resend the same webhook event and confirm nothing duplicates
• Disable one product and confirm it disappears and can’t be purchased
• In admin, move an order through statuses (new -> paid -> shipped) and add an internal note
• Deploy a small change and roll it back within minutes without losing order data

Do one real live charge before you announce anything. Use a real card, a small amount, and your own shipping address. You should see the order show up exactly once, with a clear timestamp and status.

If you’re using Koder.ai, practice this with snapshots: deploy, place an order, roll back, and confirm existing orders still load correctly.

Example scenario: a tiny store that can ship this week

Picture a small coffee roaster that wants to sell 12 bags of beans online. They don’t need subscriptions, reviews, or a loyalty program. They need a simple store that takes real money and creates clean orders they can fulfill.

By day 2, the catalog is good enough if each product has a clear photo, a price, and a short description (roast level, tasting notes, bag size). Keep options minimal: one size per product and one shipping option (for example, flat-rate shipping in one country).

By day 4, checkout does one job: collect shipping details, take a card payment, and show a confirmation page the customer can screenshot. Display an order ID and a short summary (items, total, shipping address). If a customer emails support, that order ID is the fastest way to find what happened.

By day 5, admin stays intentionally plain. The roaster signs in, sees new orders, and moves orders through paid, packed, shipped. Tracking can come later. In week one, a note like “Shipped via postal service, label printed at 3:10pm” is often enough.

This is also the kind of scope that works well with chat-first builders like Koder.ai: a small set of screens, a small set of tables, and a clear workflow.

Week 2 ideas worth waiting for: discount codes, better search, inventory counts, and more automated emails. Add them only after real orders tell you what matters.

Next steps after the MVP is live

Treat the first week live as a learning sprint. Get real orders through the system, then remove the biggest friction you can prove.

Start with a small pilot: aim for 10 paid orders from friends, coworkers, or a small audience you can message directly. Ask each person where they hesitated. Track drop-offs in a simple sheet: product page -> cart -> checkout started -> payment success.

After the pilot, add only one change at a time. The best early upgrades are usually simple: clearer shipping costs, better product photos, fewer checkout fields. Pick the next biggest blocker from your notes, fix it, and run another small batch.

Customer support will also show you what’s missing fast. Save short replies for the questions you’ll see repeatedly: where is my order, can I cancel, why did payment fail, how much is shipping and when will it arrive, can you change my address.

If you want to iterate quickly without risking checkout, Koder.ai can help you generate the next version from chat and use snapshots and rollback so you can test changes safely before pushing them live." }