9 Ecommerce Website Examples I Tested Mechanic by Mechanic

‍

A discount code is only supposed to work once. A checkout total is supposed to match the number on the confirmation page. A cart isn't supposed to let two people buy the last of something at the same time.

These are the small, unglamorous rules that separate a store that works from one that only looks finished in a screenshot.

I built three ecommerce website examples over a shared two-week window, each one a test store on Emergent.

Each build set out to test whether a written brief that spells out every rule, with nothing left to guesswork, could produce inventory logic, subscription billing, and a production queue that all hold together once a real shopper puts them to the test.

Follow along, and you'll see what each store does under the hood. That means the prompt that built it, the bug each one hit, and the mechanics worth copying into your own ecommerce website. All three run on Emergent's ecommerce builder, which turns a written description of a store into a working storefront with a real catalog, cart, checkout, and database behind it.

6 Real Ecommerce Website Examples

The six stores below are ones you've probably shopped at. Each entry names exactly one cart, checkout, or personalization mechanic and explains why it holds up.

• Allbirds keeps its size chart in a modal on the product page, so shoppers never leave the listing to check a fit, and it turns an out-of-stock size into a "Notify Me" prompt instead of a dead end.
• Glossier puts a real star-rating and review module directly on the product page, so the social proof a shopper would otherwise leave the listing to find sits next to the add-to-cart button.
• Adidas lets shoppers add a name and number to select jerseys right on the product page before checkout: a single custom line that has to carry through cart, payment, and confirmation without breaking.
• Apple runs its Mac buying flow through a single configurator: pick the chip, memory, storage, and keyboard, and each step prices against your current chip selection, the same "totals that never disagree" problem the Fieldnote Leather build below tests directly.
• Instacart asks upfront what to do if an item's out of stock (best match, a specific swap, or a refund), then lets the customer approve or decline the shopper's substitution in real time. Anchor & Awl, below, answers the same inventory uncertainty with a hard production cap.
• Burberry sets shipping region and currency from a single site-wide control, "Shipping to United States ($)", and prices the whole catalog in that currency, so the shopper sees local pricing instead of a converted figure.

Each of these mechanics shows up again in the three builds below.

How I Tested These Mechanics Myself

A photo can't show you whether the discount code enforces its one-time rule, or whether the inventory count updates when two shoppers load the same product page seconds apart.

Each of the three stores I built started from a written vibe coding prompt specific to that store: a brief laying out the exact rules the build needed to follow. Every store mechanic described in the three build sections below is one I tested by hand.

That testing approach also follows practical vibe coding best practices: review the preview, test edge cases, and make focused follow-up changes instead of treating the first pass as finished.

I judged all three stores against the same five criteria, and the section at the end shows what each looked like in practice.

Those criteria track what shoppers abandon carts over: Baymard Institute puts the average cart abandonment rate at 70.22% across 50 studies, and unexpected costs, slow delivery, and forced account creation are the top reasons cited.

They also span three different selling models on purpose. Fixed inventory, a subscription, and a made-to-order queue each carry their own version of these rules. If you run any one of those three models, you'll see the mechanic closest to your store.

3 Ecommerce Stores I Built and Tested on Emergent

Three stores, three selling models, two weeks.

Each section below covers the exact prompt used, what happened when it ran, and the one bug that came up along the way. If you'd rather browse other online store website builders before committing to one, that comparison covers how they handle the same inventory, checkout, and discount logic.

Fieldnote Leather: A Fixed-Inventory Retail Store

Fieldnote Leather is a small handmade leather goods test store selling a tote, a wallet, and a belt. I built it to test two basic things a retail store needs to get right.

Does the inventory stop two people from buying the same last-in-stock item? Does the total a shopper sees in their cart survive all the way to checkout without changing?

I wrote the brief the way a first-time store owner would, spelling out every rule in detail:

"Build me a small online store called Fieldnote Leather that sells three handmade leather goods: a Weekender Tote, a Slim Bifold Wallet, and a Two-Loop Belt. The tote and wallet each come in two colors, cognac and black. The belt comes in cognac and black too, plus three sizes: small, medium, and large, and the price should go up by four dollars for each size step above the base price of thirty-eight dollars. Every product needs its own photo, a short description, and a live inventory count for each color and size combination. When someone adds an item to their cart, hold that unit for them until checkout finishes or the hold expires, so two customers can never both buy the last belt in a size that only has one left. Calculate sales tax by the shipping state and shipping cost by order weight, and show the same estimated total on the cart page and the final checkout page; they should never disagree. Add a discount code, FIRSTORDER, worth fifteen percent off, but only on a customer's first order ever, and block it from applying again if that same customer checks out a second time. When it's done, I need to be able to export every order, customer name, items purchased, and totals, as a CSV file, and I should be the only login the store needs for now."

The Results

Here's how the three passes played out. Pass one, at 15 credits, got the catalog, cart, and checkout flow running in one shot. That included the belt's per-size price step: $38 for small, $42 for medium, $46 for large.

What it missed was the one rule the whole brief was built around. The inventory hold on the last size-medium belt didn't lock. I opened two browser tabs and raced them to checkout.

Two shoppers hitting that page seconds apart could both have walked away thinking they'd claimed a belt that could only ship to one of them.

• Before the fix: Two browser tabs could both reach the final checkout step while holding the same last-in-stock belt.
• After the fix: Only the first tab to reach checkout could complete it. The second saw the item drop to zero stock before it reached the payment step.

Pass two, at 19 credits, tightened the hold implementation after the first version failed to enforce the rule. Pass three, at 23 credits, locked down the FIRSTORDER discount's one-time-per-customer rule and wired up the CSV (comma-separated values) export.

Three passes, four days, and 31 minutes of hands-on prompting time got me to 57 credits total, for a store whose inventory hold held up under a real race condition and whose totals matched on every test run.

For a first storefront that still needs its inventory and checkout logic proven out, a written brief got me to a build solid enough to survive the same two-tab race that caught the missed inventory hold.

Here's what the Fieldnote Leather build proves:

• Variant pricing that calculates correctly: The belt's size-based pricing applied to every color and size combination without needing a manual price table.
• A discount code with an enforced exception: FIRSTORDER discounted a shopper once and never again.
• Cart and checkout totals that never disagreed: The same estimated total, tax and shipping included, showed up on both pages every time I tested it.
• A CSV export that's usable right away: Every order, customer name, item, and total exported cleanly, behind the same single login the brief called for.

The BigCommerce vs Shopify test pushes the same variant question much further, using a 126-combination product on each platform.

Trailmix Coffee Co.: A Subscribe-and-Save Coffee Store

Trailmix Coffee Co. is a test store built around recurring billing, selling three roasts, light, medium, and dark, each as a one-time purchase or a subscribe-and-save order.

I wanted to know whether a subscriber's locked-in price survives a price increase or resets when a subscriber skips a shipment. That is the kind of lifecycle logic website builders for subscription services need to handle beyond a one-time checkout.

I built the brief around two opposite pricing rules that had to work inside the same shipment, something a one-time-purchase store never has to handle:

"Build me a small online store called Trailmix Coffee Co. that sells three roasts, a Light Roast, a Medium Roast, and a Dark Roast, each a twelve-ounce bag priced at sixteen dollars, with its own photo and a short tasting notes description. Alongside a one-time purchase, add a subscribe and save option on each roast, so a customer can choose a fresh bag every two weeks, every four weeks, or every eight weeks, at fifteen percent off. Whatever price a subscriber locks in on signup day has to stay their price for as long as that subscription runs, even if I raise the one-time price on that roast later, but if that same subscriber adds one extra bag to a single shipment, that extra bag is charged at whatever the current one-time price is that day, never their locked price. Let a subscriber skip their next shipment or change frequency from their account page without canceling the subscription, and make sure the next ship date on the account page always matches the date on their most recent checkout confirmation; they should never disagree. Add a first-time subscriber code, ROAST10, ten dollars off, that only works on a brand new subscription, never on a one-time order and never on a second subscription from someone who already has one. When it is done, I need to export my subscriber list, roast frequency, and next charge date as a CSV file."

The Results

The two passes went like this. Pass one, at 13 credits, got the catalog, the one-time purchase flow, and the subscribe-and-save option running. That option ran at 15% off, with delivery every two, four, or eight weeks.

I signed up a test subscription myself, then went back and raised the one-time price on that same roast. My locked price held through the increase. I also placed a second test order for an extra bag on that same shipment, to see how it would be priced against my locked rate.

• What held: The locked price survived the one-time price increase, and an extra bag added to that same shipment was still charged at the new, higher rate, matching the split the brief called for.
• What broke on a skip: The build canceled the subscription and recreated a new one, when it should have kept the existing cycle in place. That reset the locked-in price to the current, higher one-time rate, even though a shipment skip isn't supposed to touch pricing at all.

Pass two, at 9 credits, spelled out that a skip has to preserve the original locked price without recreating the subscription. I skipped again, and the price held.

The two passes used 22 credits and 24 minutes of hands-on prompting time across two days.

I also redeemed ROAST10 on a fresh subscription, then tried it again on a repeat order to check it wouldn't reapply. It didn't. Comparing the next-ship date on the account page against the checkout confirmation after each change, the two matched every time.

The Trailmix Coffee Co. build proved this:

• A price lock that survives a price change: An increase to the one-time price didn't touch what an existing subscriber pays.
• A skip that preserves the subscription and locked price: Skipping a shipment left both in place.
• The next-ship date matched in my tests: The account page and the checkout confirmation showed the same date when I compared them.
• A one-time code that respects new versus existing subscribers: ROAST10 worked on a first subscription and nowhere else.
• Frequency changes with no cancellation required: The switch between two, four, and eight weeks worked directly from the account page.
• A subscriber CSV that exported cleanly: Roast, frequency, and next charge date came out in one file, ready to open

Anchor & Awl: A Made-to-Order, Capacity-Capped Store

Anchor & Awl is a test store that sells one product, a personalized engraved maple cutting board, made to order against a hard daily production cap.

Fieldnote Leather runs on fixed inventory, and Trailmix Coffee Co. runs on recurring billing. Anchor & Awl adds a capacity limit that keeps each production day to six orders. Proof approval controls when a production slot gets reserved.

A slot belongs to a shopper only once they approve their engraving proof, well after they place the order:

"Build me a small online store called Anchor and Awl that sells one product, a personalized engraved maple cutting board, for sixty-eight dollars. I can only finish six of these a day, so once six orders are placed for a given production day, the seventh order and every one after it that day needs to automatically move to the next open day instead of piling onto one that is already full. Show the customer their real estimated ship date at checkout, and show that exact same date again on the order confirmation page right after payment; they need to always match, even if other customers checked out around the same time and that day's slots filled up in between. Before any order enters the production queue and takes up one of that day's six slots, the customer has to see and approve a text preview of exactly what will be engraved, so a typo never gets carved into a real board. If a customer approves their proof late, after that day's six slots are already taken, bump them to the next open day instead of forcing a seventh order into a full one."

The Results

It took three passes to get there. Pass one, at 11 credits, got the single-product catalog, the engraving text field, and the six-orders-a-day cap running. I placed six test orders back-to-back to fill a production day. The seventh rolled over to the next open day, without overbooking the first.

The proof-approval timing didn't work. I placed one test order and left its proof unapproved, then placed and approved five more test orders behind it. The build had already reserved a slot for the unapproved order the moment I placed it, well before anyone confirmed it.

• Before the fix: A production slot got reserved the instant an order was placed, whether or not the proof behind it was ever approved.
• After the fix: A slot was reserved after proof approval, before the order entered the production queue.

Pass two, at 8 credits, moved slot reservation later in the flow but didn't fully separate the two events. Order placement and approval still overlapped inside a short review window, though the overlap was harder to trigger than before. Pass three, at 7 credits, cleanly separated the two events and fixed it.

I re-ran the test with one change: six approved orders behind the unapproved one, enough to fill the day on their own. It worked the right way around.

My slow, unapproved test order bumped to the next day once its proof came through, and the six approved orders ahead of it kept their slots.

All told, that's 26 credits across three passes and 27 minutes of hands-on prompting time, spread across three days.

A single hero product with a finite production ceiling is exactly where Emergent's capacity queue earned its keep. Six slots a day meant six slots a day, a hard cap that held in every test I ran.

The proof-approval timing is still worth spot-checking by hand before you trust it on a real production day.

What came out of the Anchor & Awl build:

• A daily cap that held in my test: Six orders filled a production day, and the next one rolled over to the following day every time I tested it.
• The displayed ship dates matched before the late-approval change: The checkout and confirmation pages showed the same date while I filled the remaining slots.
• A slot claimed only once the proof was approved: Every order required a text-preview approval before it entered the queue.

What Makes These Examples Work

I built three completely different stores, and the same handful of mechanics kept deciding whether each one worked.

Five things every build had to get right:

1. Clear, non-duplicated navigation: Keep menu labels distinct and specific, and make sure each one leads exactly where it says it will.
2. A value proposition stated honestly, right up front: Fieldnote Leather is handmade. Anchor & Awl is made to order. Either reason could make a shopper pick one over a mass-market alternative, so it belongs at the top of the page where a shopper sees it first.
3. Enough product-page detail to answer a shopper's question: List size, materials, what's included, and what happens next on the product page. Trailmix Coffee Co. presents its frequency choices and price-lock rule alongside the 15% discount.
4. Totals and ship dates that stay consistent across pages: Fieldnote Leather's cart and checkout totals matched on every test run. Anchor & Awl's checkout and confirmation ship dates matched while I filled the remaining slots, before the late-approval fix. These tests checked the displayed values; confirming server-side recalculation requires a code-level check.
5. Mobile-first, low-friction checkout: Keep the path from cart to confirmation short and predictable, especially on a phone. Avoid unexpected fields, screens, and steps.

Limitations of an AI-Built Example Store

None of the three limitations below surfaced in the builds above, but each is worth knowing before you scale past a small test store:

• PDF and printable report generation is weak: Emergent's PDF output can introduce random page breaks inside charts. It doesn't affect any of these three stores, but a store that leans on printable, invoice-style order reports should factor it in.
• Preview and production use separate databases: Sending a new build to production preserves the production database, while preview data, images, and files do not move over automatically. These three test builds each went through only a couple of build updates to check the logic, and none stayed live afterward. Trailmix Coffee Co.'s price-lock logic in particular depends on price changes landing cleanly, so a store planning frequent catalog or price updates should know this going in.
• Resource-consumption visibility at extreme scale isn't there yet: Multiple users share MongoDB cluster resources. If an app causes resource issues, Emergent may temporarily block further deployments. These three test builds didn't hit that constraint, but resource use can become a concern as an app grows.

If you're planning something bigger than a small test store, pricing out six different routes to building a website is a useful next stop before you commit to one.

A step-by-step walkthrough of building a store website covers the setup process from an empty account to a working storefront.

How Emergent Helps You Build Your Own Example

A finished-looking store still needs tests for its inventory hold, its discount code's enforcement, and its subscriber price-lock under a price increase.

Emergent's ecommerce builder handles exactly those rules. Its four documented feature groups cover several of the mechanics tested across the three stores above.

Those groups are product catalog and store setup, payment and checkout, product management, and promotions and sales. Variant-based products, inventory logic, custom checkout flows, and discount rules all get defined by describing what you want in plain language.

If you're weighing Emergent against other options, a rundown of the AI tools built for ecommerce is a useful starting point.

A closer look at the AI ecommerce website builders worth considering goes deeper into how they compare on inventory, checkout, and subscriptions, the mechanics that decide whether a store holds up.

You can build this flow without writing code yourself by describing the store you want, which is the basic workflow behind a generative AI app builder. The same build system scopes it, puts together the catalog and checkout logic end to end, and checks the result before you see it. All three stores I built went through that sequence.

Here's what you can do with Emergent:

• Describe variant-based products in plain language: Sizes, colors, and other options, along with the pricing rules attached to them, get built out without a manual price table.
• Attach inventory or capacity logic that matches how you sell: Fixed-stock holds, subscription price locks, or a hard daily production cap can all be defined by naming the rule, without configuring it field by field.
• Set up discount and subscription rules that enforce themselves: One-time codes, first-time-buyer offers, and skip-without-canceling logic all get built from a written description of when they should and shouldn't apply.
• Keep checkout totals consistent across pages: Tax, shipping, and totals stay consistent from the cart to the confirmation page.
• Export what you need to run the store day to day: Orders, customers, and production queues come out as CSV files without a separate reporting tool.

Emergent built all three test stores in this piece, and it's the same starting point for building your own ecommerce website examples.

Curious whether your own store idea can handle real shoppers? Try Emergent's ecommerce website builder and put the same mechanics to the test.