Does an AI Builder Work for Ecommerce? What It Handles
For a focused store, yes. Describe the shop, connect Stripe, and the generated site opens real checkout sessions with the money landing in your account. Connect Supabase and it can store orders and accounts. Where it gets thin is scale: thousands of products, warehouse logistics and complex tax rules are a different kind of software.
So the useful question is not whether an AI builder does ecommerce, it is which shop you are building. This post draws that line concretely, because "it depends" is not an answer anyone can act on.
What does an AI builder actually generate for a shop?
The storefront and the path to payment. Product pages, a catalogue layout, a cart or a direct buy flow, a checkout session, a success page, and an account area if you connect a database.
Card data never touches the generated site, which removes the scariest part of the question. Stripe hosts the checkout page, so the app creates a session and redirects, and the card number is handled under Stripe's compliance rather than by code a model wrote last Tuesday.
What arrives is a working shop rather than a mock-up. Every build is booted in a sandbox before it reaches you, and one that fails to load is reported as a failure rather than handed over. That lowers the risk of publishing something blank; it does not remove it, and it says nothing about whether your prices are right, which is why you still test a purchase yourself.
Which kinds of shop does it suit?
The dividing line is not size of ambition, it is how much of the business is rules rather than pages.
| Shop shape | Verdict | Why |
|---|---|---|
| A handful of products, one currency | Well suited | This is mostly pages and one checkout |
| Digital goods, downloads, access passes | Well suited | No shipping, no stock, no returns logistics |
| Subscriptions and memberships | Well suited | Stripe handles recurring billing; access rules come from edits |
| Services and bookings with a deposit | Well suited | A form, a price and a checkout |
| A few dozen products with variants | Workable | Expect several edits to get variants and stock behaving |
| Hundreds or thousands of SKUs | Poor fit | Catalogue management, not web design |
| Marketplace with multiple sellers and split payouts | Poor fit | Payout logic is genuinely complex software |
| Multi-warehouse, multi-country tax and fulfilment | Poor fit | This is an operations system with a shop attached |
The top half of that table is a large share of real online selling. The bottom half is where a dedicated ecommerce platform or a development team earns its money, and pretending otherwise would cost you weeks.
What do you need before the first build?
Three things, and only one runs on somebody else's clock.
A Stripe account, which is free to open and where the verification wait lives. You can build and test the entire purchase flow with test keys while that runs, then swap in live keys, since nothing in the generated code changes between the two.
A decision about what you sell and at what price. "Add a shop" is a weak brief because it leaves currency, product structure and delivery undecided, so the build guesses and you spend edits correcting the guess. "Four candles at 24 euros each, one variant for scent, flat-rate shipping in Portugal" produces something you can test immediately.
Your product photographs. Builds arrive with stock imagery so the layout can be judged, and on a shop the product photos are not decoration, they are the content. Replacing them is the first edit worth making, as covered in can I use my own images.
How much of ecommerce is not the website at all?
Most of it, and this is the part that decides whether a store works. The split is worth being blunt about.
Generated for you: the storefront, the product pages, the checkout session, the order record if a database is connected, and the transactional email through Resend. Handled by Stripe: card entry, receipts, subscription billing and the payment security surface.
Yours, unavoidably: tax registration and filing, shipping rates and carriers, stock counts that match reality, returns, refunds, disputes, customer support, and the terms you publish. Stripe also decides which businesses it will serve, and no builder routes around that.
An AI builder compresses the construction of the shop from weeks into an afternoon. It does not compress the obligations of running one, and after the software collapses to an afternoon that list above becomes the actual project. The mechanics of wiring the payments are in can AI build a site that takes payments.
What does a store cost to build in credits?
A shop is usually a multi-page platform rather than a single page. That costs 12 credits for the first three pages and 3 for each page after, so a home page, a catalogue, a product page, a checkout success page and an account page is a predictable increment rather than a surprise. A simple one-page build costs 6, an edit costs 3, and Hi-Fi mode doubles the build and the edit.
Free comes with 5 credits, Pro is $25 per month with 200 credits, and Business is $99 per month. Pro's allowance works out to 16 full platforms, or 66 edits if edits are all you spend on, which matters here because a shop is an iterative object.
Budget for the iteration rather than the build. Getting a store right means changing prices, adding a variant, rewording a guarantee, moving a button and testing the purchase again. Expecting a dozen small corrections is realistic; expecting one perfect prompt is not. The full pricing breakdown is in AI app builder pricing.
What should you test before you take real money?
Buy your own product. In Stripe test mode, with a test card, from the product page to the success page to the record appearing in Stripe. Fifteen minutes of this catches things no automated check is looking for, because a checkout that charges the wrong amount loads perfectly.
Then check the parts that only fail with real people. Open the store on a phone, because that is where most of your visitors will be. Buy the variant, not just the default. Try to buy something that is out of stock. Enter a delivery address in a country you did not think about.
Finally, look at the address bar. A shop on a builder subdomain asks for a card at a disadvantage, and connecting your own domain is a one-time DNS change described in can I use my own domain.
Where does this approach genuinely stop?
At catalogue scale and at payout complexity, for two different reasons.
Catalogue scale stops it because managing thousands of products is a data problem with a web interface attached, and describing it in prose is the wrong tool. Feeds, bulk edits, imports and inventory sync are what dedicated ecommerce platforms are built around, and they are better at it. Saying so is not modesty, it is accuracy.
Payout complexity stops it because marketplaces, split payments, usage metering and complicated proration are the kind of specificity that arrives through a series of edits rather than one prompt, and past a certain point through a developer. Zugo does not replace a development team on a complex product, and a store with real revenue eventually justifies one. When that moment comes, export to GitHub and the project continues as an ordinary repository, which is covered in can I export the code from an AI builder.
What is the practical recommendation?
Start narrower than you think. A shop with four products that works, takes real money and is live this week teaches you more than a plan for a hundred products that ships next quarter. If the four sell, adding more is edits.
That order also protects you from the expensive version of the mistake, which is building a large catalogue for demand you have not verified. The builder's advantage is not that it makes big stores; it is that it makes the first real one fast enough that you can find out.
Describe your shop at zugo.dev, connect Stripe in test mode, and buy your own product with a test card. If that loop works, the rest is pricing, photography and paperwork. For a wider walkthrough of the storefront itself, see the AI online store builder guide.