AI store builder or Claude Code?

Both make a store that looks fine. The rendering stopped being the difference some time ago.

The difference is who holds the walls. A hosted AI store builder writes the page, builds it, hosts it, runs the checkout and the emails, and keeps all of that on its own infrastructure. An agent working in your repository writes files onto your disk and hosts nothing at all. So the real question is not which one is better at HTML. It is: on the day you stop paying, or the platform changes its terms, or the account is suspended by a machine at three in the morning, what is still standing?

If the answer has to be my store, you want the code. If the answer can be I will move, the builder is often the smarter use of your month.

What are you actually choosing between?

One of them is a place, the other is a tool.

The hosted builder is a place. You get an account, a chat box, a URL, a database, a checkout, a dashboard and a bill. Everything is already wired. You are renting a running shop and describing the changes you want.

The agent is a tool. It edits a project you already had, runs your commands, commits to your git history. It has no opinion about where the thing is deployed because deployment was never part of it. You are keeping the shop and hiring a very fast pair of hands.

Neither is the amateur option. Plenty of stores taking real money run on a hosted builder, and plenty of repositories with an agent in them never ship.

Who owns the walls?

These are the criteria you can check before signing up, rather than after.

That last line is the one people find out late. A hosted builder's best features are frequently not in the page at all: the discount engine, the abandoned-cart email, the tax table, the order dashboard. Export gives you the front end. The machinery stays behind.


What does the money actually say?

Less than people expect, and it is worth working through rather than assuming.

Take a store at $55 average order value. Assume a hosted plan at $39 a month plus a 1% share of order value, and an owned stack at $20 a month of hosting. Card processing is charged on both sides at the same rate, so it cancels out and we leave it out. These are stated assumptions, not measurements — swap in your own and the shape holds.

At 20 orders a month the difference is $30, which is not a decision. At 600 it is $349, which is real money and still less than a day of contract front-end work. So the arithmetic does not settle it in either direction. Anyone selling you either option on cost alone is selling you the wrong axis.

What the table does show is the shape: the hosted bill grows with your success and the hosting bill mostly does not. If you expect the order count to multiply, that slope is the thing to look at, not this month's figure.

When is a hosted builder the right call?

Honestly, more often than a developer audience likes to admit.

• You are testing whether anybody wants the product. The store is a question, not an asset. Get it up this week.
• Nobody on the team writes code, and nobody is going to start. An owned repository with no one to maintain it is a liability with a domain name attached.
• You need tax, invoices and returns handled today. These are unglamorous, they are legally binding, and they take longer to build than the shop.
• The catalogue is the work. Three hundred SKUs with variants and stock are a data problem. Fighting that in a bespoke codebase is a choice you should make deliberately.

When is it the wrong one?

• The store is the business. If the whole company is that URL, renting the walls is a single point of failure you did not price.
• You sell something a platform may decide it dislikes. Categories drift in and out of favour. The suspension email arrives before the appeal does.
• You already have a codebase, a design system, a stack. Then the builder is a second system to keep in sync with the first.
• The mechanics you need are specific. Every platform has a ceiling shaped like its app store. The moment you want a component that does not exist as an app, you are writing code anyway, inside a template you do not control.

How do you test ownership before you commit?

Do not read the marketing page. Export on day one, before there is anything to lose, and run this:

git clone <the-export-you-were-given> store && cd store
npm ci
npm run build
npm run start        # then open it, click add to cart, click checkout

Three outcomes, and they tell you exactly where you stand. It builds and the checkout works: you genuinely have the thing. It builds but the checkout is a stub pointing at the platform's API: you have the front end and are renting the till. It does not build without an account key in the environment: you have a skin.

What you own, you also run

The other half of ownership is the part the platform was quietly doing. Payment succeeds at the provider, and something on your side has to hear about it and record the order. That something is yours now:

// app/api/webhooks/stripe/route.ts
import Stripe from 'stripe'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)

export async function POST(req: Request) {
  const signature = req.headers.get('stripe-signature')
  if (!signature) return new Response('missing signature', { status: 400 })

  // Raw text, never JSON.parse first: the signature is computed over the bytes.
  const body = await req.text()

  let event: Stripe.Event
  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!,
    )
  } catch {
    return new Response('bad signature', { status: 400 })
  }

  if (event.type === 'checkout.session.completed') {
    const session = event.data.object
    // Idempotent by event id: providers retry, and they retry more than once.
    await recordOrderOnce(event.id, session.id, session.amount_total)
  }

  return new Response('ok') // answer fast, or the retries pile up
}

That is forty lines you never wrote on a hosted builder, and it is the cheap end of the list. Emails, refunds, VAT rates, invoice numbering, an order view someone can actually use on a phone at the post office. Count those hours before you call the monthly plan expensive.

The rest of that list, and the specific things that break between the code runs and someone paid, is in vibe coding a store: what breaks at checkout.

What neither one gives you

Selling mechanics. This is the part both sides are equally silent about, and it is why so many stores from both camps look competent and convert badly.

Neither a hosted builder nor an agent decides, on its own, that the three-pack should be the default selection, that the remaining amount to free shipping belongs in currency rather than as a percentage, or that the complement is offered after the add-to-cart rather than before. Those are decisions, and a generator with no constraint returns the median of what it has seen — a phenomenon we took apart in why every AI generated landing page looks alike. Whether a longer prompt fixes it is a separate question with a disappointing answer.

uxgen is an MCP that hands a coding agent those components as HTML the merchant keeps, from $19 a month. We have no paying customers yet, so take that as a description rather than a recommendation. The four cart mechanics are MIT and readable now: github.com/kinerette/uxgen-commerce-kit.

FAQ

Is an AI store builder good enough to launch a real store?

Yes, and many running stores are exactly that. The limit is not output quality, it is where the store lives: the pages, the checkout, the customer data and the order history sit on the platform's infrastructure under the platform's terms. That is a fine trade while you are finding out whether the product sells, and a risk once the store is the business.

Do I own the code an AI store builder generates?

Read the terms, then test it. Many platforms will export a repository, but the export is usually the front end. The discount engine, the abandoned-cart emails, the tax tables and the order dashboard were platform features rather than files, and they do not come with it. The only honest check is to export on day one, clone it, build it offline, and try to place an order.

Is Claude Code cheaper than an AI store builder?

Not reliably, and cost is the wrong axis. On a store at $55 average order value with a $39 plan plus a 1% order share against $20 of hosting, the gap runs from about $30 a month at 20 orders to about $349 at 600 — real, but less than a day of contract work either way. What differs is the slope: the platform bill grows with your order count, hosting mostly does not.

Which one makes a store that converts better?

Neither, by default. Both produce the same competent, generic product page, because with no constraint a generative system returns the most common arrangement it has seen. Conversion comes from specific decisions — which variant is preselected, where the complement is offered, what the shipping line says — and those have to be supplied, by a component library, a spec, or you.