We built a full e-commerce store in a weekend. Here's the exact playbook.

Why a weekend is even possible

Five years ago this build was a two-to-three-month agency project. Three things changed the math:

• The decisions are known. An online store is not a novel problem. Cart, checkout, variants, order states, refunds — the shape of the system is settled. What kills timelines is re-deriving it from scratch, meeting by meeting.
• AI handles the repetitive 80%. We run Codex and Claude in the loop for scaffolding, CRUD, forms, admin tables and test coverage. That's most of an e-commerce codebase by volume — and almost none of it by risk.
• The stack is boring on purpose. One repo, server-rendered pages, Postgres, Stripe. No microservices, no exotic infra. Boring stacks have no surprises, and surprises are what weekends can't absorb.

None of this works without the third ingredient: a scope that's frozen before the first commit. More on that below, because it's where most fast builds die.

Friday: decisions before code

Friday evening is not a coding session. It's a two-hour working call with the client where we lock the things that are expensive to change later:

• The catalog model. How many products, which ones have variants (size, colour, flavour), and whether bundles are fixed sets or build-your-own. This one decision shapes half the schema.
• The money path. Stripe checkout, which currencies, tax handling, shipping rules (flat, tiered, or free-over-X), and the refund policy. We write these down as plain sentences the client signs off on.
• Order lifecycle. The states an order can be in (paid → packed → shipped → delivered, plus cancelled and refunded) and who moves it between them.
• What's explicitly out. For this build: no customer accounts at launch, no loyalty points, no multi-warehouse stock. Written down, agreed, revisitable after launch.

By Friday night we have a one-page spec, a data model sketch, and a scaffolded repo with CI, deploy pipeline and a hello-world page already live on the production domain. Deploying on day zero matters: every commit after that is shipping, not preparing to ship.

Saturday: the build day

Saturday is storefront and checkout — the customer-facing half. The rhythm is the same all day: we write the spec for a slice (say, the product page with variant selection), AI produces the implementation and tests, a human reviews the diff like it came from a junior engineer with infinite typing speed, and it merges when it's actually right.

What shipped on Saturday:

• Product listing and product detail pages, with variant selection that respects stock levels
• Cart with bundle logic — bundles priced as sets, discounted against individual prices
• Stripe Checkout integration, including webhooks for payment confirmation — written by AI, reviewed line by line by us, because money code gets human eyes no matter how confident the diff looks
• Order confirmation emails and a "where's my order" status page

The parts that took real human time were exactly the parts you'd expect: getting the bundle discount logic to match how the client actually prices things (their spreadsheet had three undocumented exceptions — there are always three undocumented exceptions), and making the storefront feel like their brand instead of a template.

Sunday: the admin panel and the boring 20%

Sunday is the half the customer never sees, and it's what separates "a demo" from "a store you can run a business on":

• Admin panel — products, stock, prices and bundles editable by the client's team, not by us. Orders searchable, filterable, and movable through the lifecycle with one click.
• Stock handling — decrement on purchase, low-stock warnings, and out-of-stock states that actually reflect on the storefront.
• The edge cases — failed payments, double-submitted checkouts, refund flow tested against Stripe's test cards, and a webhook retry story so a dropped connection doesn't lose an order.
• A real QA pass — full purchase flow on desktop and phone, every email checked, every admin action exercised. The last two hours of a weekend build are always testing, never features.

Sunday evening: DNS cut over, the client's team walked through the admin, first real order placed. Live.

What we deliberately didn't automate

The honest part. AI wrote most of the code by volume, but the build worked because humans owned four things:

1. Scope. The Friday call is judgment, trade-offs and saying no. No model does that for you.
2. Money paths. Checkout, webhooks and refunds got line-by-line human review. A plausible-looking bug in payment code isn't a bug, it's an incident.
3. Taste. Spacing, type, the feel of the storefront. AI gets you to "fine". Clients don't pay for "fine".
4. The final QA pass. A human clicking through the store the way a rushed customer on a phone would. Every build, no exceptions.

What breaks weekend builds

We've seen fast builds die three ways, so we design against all of them:

• Scope reopening mid-build. "While you're in there, could we also…" — after launch, gladly. During the weekend, the answer is no. That's not rigidity; it's the only reason the date holds.
• Content not ready. Product photos, descriptions and prices need to exist on Friday. A store can't ship faster than its catalog.
• Exotic integrations. Stripe is a weekend. A legacy ERP with a SOAP API from 2009 is not. We scope those honestly as their own project — see what custom builds really cost.

What this costs

A build like this is our Online Store package — from $6,000, fixed. Fixed means fixed: the number and the date are agreed before we start, 50% up front, the balance when it ships, and the client owns the code, the Stripe account and the infrastructure. No retainers, no per-transaction cut, no lock-in.

For comparison, the agency quotes this client had collected ranged from $28,000 to $60,000 with eight-to-twelve-week timelines. Where that 5× markup comes from is its own post.

The takeaway

Speed in software isn't heroics and it isn't corner-cutting. It's decided scope, a boring stack, AI on the repetitive volume, and human judgment concentrated on the four places it actually matters. That combination is repeatable — we run the same playbook, sprint after sprint.

If you're checkout-over-DMs today, that's exactly the shape of business this playbook was built for.