# Vibe-Code the Storefront, Not the Commerce Engine > AI coding agents are good at storefronts, where mistakes show. Keep them off the engine, where money moves. How GoCommerce and Svelte Commerce split the work. - Canonical: https://kitcommerce.store/vibe-coding-commerce/ - Last updated: 2026-09-25 --- Vibe-coding commerce ## Vibe-code the storefront, not the engine AI coding agents are good now. The question is what to point them at: the layer where a mistake shows on the screen — the storefront, the landing page, the integration. A commerce engine is where prices are worked out, stock is promised and money changes hands, and its mistakes surface later, as money. Build that layer against an engine that already exists. GoCommerce is an open-source one, documented to the operation and written to be read by an agent. - **342** documented operations - **19** MCP tools - **1,000+** tests - **1** production dependency The appeal ### The demo works. That was never the question. Ask a coding agent for a commerce API and you will get one: a catalogue, a cart, a checkout and a payment integration that compile, pass their tests and click through cleanly. That part is real. The tests it wrote are the tests it thought of. Commerce breaks in the cases nobody asked about: two requests at once, the same webhook twice, an order edited after its discount was applied, a gateway that answers after the order already exists. None of these is exotic. They just never come up in a demo, so they come up later — with real orders attached. The two layers ### The layer you can see, and the layer you can’t A storefront is something you can look at, click through and throw away. An engine is a ledger with a state machine attached: when it is wrong, nothing on the screen says so. Keep the line between them clean. Experience layer #### Vibe-code it A mistake here is visible: you see it in a browser, fix it and ship again. - Storefronts — Svelte Commerce and its 79 themes, or one written against the API - Landing pages, campaign pages and content - Admin-side tools and reports over the admin API - Integrations — ERP, CRM, email — over the webhooks module’s signed events - Agent entry points — agents that run the store, over the MCP module [See the 79 themes](https://kitcommerce.store/svelte-commerce/themes/) Engine layer #### Don’t A mistake here is silent: it surfaces weeks later, in a reconciliation or a refund. - Order lifecycle — controlled transitions, payment and fulfillment as separate states - Inventory on hand and reserved, per location - Price lists by customer group, quantity and channel - Discounts, their usage limits, and what an order edit does to them - Refunds, recorded before the gateway is asked - Money as integer minor units, never a float - Payment modules and their signed webhooks [GoCommerce is this layer](https://kitcommerce.store/gocommerce/) The rule: vibe-code the layer where you can see a mistake. Build against an engine for the layer where you can’t. A misaligned button is on the screen the moment it ships. An oversold unit, a discount rounded the wrong way or a refund paid twice turns up weeks later as money that is not where the books say it is, and the trail back to the cause is weeks old too. Svelte Commerce’s GoCommerce connector is [early, at 0.1.0](https://kitcommerce.store/gocommerce-svelte-commerce-connector/): catalogue, cart, checkout and order lookup, not yet customer accounts or search. Svelte Commerce also runs against [26 other backends](https://kitcommerce.store/svelte-commerce/backends/), and a GoCommerce storefront can instead be one you write against the API. Side by side ### On GoCommerce, and from scratch Same agent, same prompts. The difference is what the agent is asked to invent. Nothing in the from-scratch column is impossible — it is work the engine column has already done and tested. Checkout · with GoCommerce #### Checkout is one call, in two phases One transaction validates the cart, re-prices it under a lock, reserves the stock and creates the order. Only after it commits is the payment provider called, so a slow gateway never holds a lock. Send an `Idempotency-Key` and a retried request resumes the same order instead of creating a second. A price that moved or stock that ran out comes back as a per-line conflict for the storefront to show the shopper. Checkout · from scratch #### The paths nobody described An agent will write a working checkout in an afternoon, and it will be right for the path you described. The work is in the paths you didn’t: a double-tapped Pay button, a price changed while the cart sat open, a gateway that times out after the order row exists. Each has a known answer. Each is also another prompt and another test, and they tend to be found after launch rather than before. Stock · with GoCommerce #### Stock is counted per location, under a lock On hand and reserved are held per variant, per location. Every movement is one statement that checks and changes under the same row lock, so two checkouts for the last unit resolve instead of racing — the second re-checks after the first commits. Checkout reserves, a sale converts the reservation, a cancellation releases it, and every movement writes a row to a stock ledger in the same transaction. Stock · from scratch #### Last unit, two checkouts “Check the stock, then decrement it” passes every test that sends one request at a time. Overselling needs two at once, which a demo never does. The fix is well known — row locks or conditional updates — but someone has to ask for it, and a second warehouse turns it into a routing question as well. Promotions and price lists · with GoCommerce #### Discounts and price lists are records, not branches A discount is a percentage, a fixed amount or free shipping, scoped to the order, products, collections or categories, with dates, a minimum and a usage limit claimed inside the checkout transaction. Price lists resolve by customer group, quantity and channel. Integers throughout, one rounding per basket, and a discount can never exceed what it discounts. The edge today: one code per checkout, and automatic discounts are not applied yet. Promotions and price lists · from scratch #### Every promotion is a decision Ten percent off is one line. Ten percent off two categories, above a minimum, until Friday, for the first hundred orders, on an order that is edited afterwards, is a string of decisions: round per line or per basket, what an edit does to the discount, who gets the last use. An agent will make every one of those decisions. It will not always tell you it made them. Payments · with GoCommerce #### The shopper pays in the provider’s own form Nine payment modules — Stripe, Razorpay, Adyen, Paddle and five more — plus cash on delivery in the core. The Stripe module creates a PaymentIntent and hands the storefront its client secret; the Razorpay module creates a Razorpay order. The card is entered with the provider, not posted to your server. In both modules a webhook marks the order paid only with a valid signature, and a repeated event cannot settle an order twice. A refund is recorded as pending before the gateway is asked, so two refunds cannot spend the same money. Payments · from scratch #### The webhook is where it goes wrong An agent will wire a payment SDK quickly, and usually reaches for the provider’s hosted fields — the right call. The risk is at the other end: an unverified webhook, a replayed one, the same event handled twice, an order marked paid on the browser’s word. Each is a line of code. Missing any one of them ships goods nobody paid for, and a test suite written for the happy path will not notice. The API · with GoCommerce #### The contract is written down 342 operations across the engine and its modules, every one in a published OpenAPI document that a running store serves at `/docs`. A rule in `AGENTS.md` says every served route must appear there. An agent reads the contract instead of guessing from handler code. The admin panel uses the same contract, so there is no private channel it can call and your client cannot. The API · from scratch #### Is session forty’s API the same as session one’s? Without a contract that something enforces, each session names things its own way: `total_price` in one response, `amount` in the next, cents here and a decimal string there. You can generate an OpenAPI file for a scratch-built API too. The discipline is keeping it true, and that is a habit, not a prompt. Channels and B2B · with GoCommerce #### A new channel is a row, not a fork Channels publish parts of one catalogue, each with its own price lists. Customer groups and quantity breaks give wholesale pricing, and scoped API keys let a buyer’s system order by machine. Marketplace vendors arrive pending and are approved or suspended. The edges: channels scope publishing and price, not orders; there is no quotes or approvals workflow; vendor commission is recorded, not settled. Channels and B2B · from scratch #### A second kind of buyer The price function the agent wrote assumes one price per product and one storefront. Then a wholesale buyer wants their own prices, and a second storefront wants a different range. Teaching a price function that assumed one kind of buyer about groups, quantities and channels is possible. It is also where the shortcuts of the first month tend to get paid for. Every claim in the GoCommerce column can be checked in the repository: `core/checkout.go`, `core/inventory.go`, `core/discounts.go`, `core/pricing.go`, `core/channels.go`, `core/orders.go`, and the payment modules under `ext/`. The agent’s toolkit ### What an agent gets to read Don’t vibe-code an engine from nothing. When you do change this one — it is MIT, and changing it is expected — the rules are written down, the contract is published, and a test suite is waiting for the wrong edit. - **342 operations in OpenAPI** — The engine and its modules in one contract, served by a running store at `/docs`. A storefront agent’s first read. - **An MCP module with 19 tools** — Operates a running store through the same services a REST call uses, never the database. `ReadOnly` withholds the 10 that change anything. - **`AGENTS.md` — 14 rules, 4 agent notes** — Money is integer minor units. A state change and its event commit together. No transaction is held across a network call. - **`skills/` — 15 task guides** — Checkout, discounts, inventory, orders, payments and the rest. An agent loads the one for its job instead of reading everything. - **1,000+ tests** — Run against a real PostgreSQL, not a mock, so a wrong edit fails in the suite instead of in a customer’s checkout. - **One production dependency** — The Postgres driver, pgx. A graph small enough for an agent to hold, with little underneath it to upgrade. *The MCP module’s 19 tools* | Read (9) | `store_info`, `store_health`, `list_products`, `get_product`, `list_low_stock_variants`, `list_orders`, `get_order`, `list_customers`, `sales_report` | | --- | --- | | Change (10) — withheld under `ReadOnly` | `update_variant_inventory`, `set_variant_price`, `create_product`, `update_product`, `create_discount`, `mark_order_paid`, `cancel_order`, `create_fulfillment`, `mark_order_delivered`, `refund_order` | The MCP endpoint inherits the admin’s authentication, so the store’s admin token is the agent’s credential. `gocommerce doctor -json` is the machine-readable health check: it exits non-zero when something is wrong, so it can gate an agent’s work without being parsed. Honest take ### When vibe-coding from scratch makes sense Not every store needs an engine. These three rarely do. #### A one-off promo store A campaign page, a short product list and your payment provider’s hosted checkout. It runs for a month and is switched off. There is nothing to maintain, so there is little to get wrong. #### An internal prototype A proof of concept to test demand or make a case. It is explicitly disposable, and nobody is going to reconcile its takings. #### A very narrow store One product, one market, one currency, no discounts, stock you can count on your fingers. If the commerce logic fits on one screen, an engine may be more than you need. Once there is real stock, a refund to issue, a discount with a limit or a second market, the engine is the part not to improvise. It does not have to be GoCommerce. It should be something written, tested and documented before your first order, not after it. Where it stands ### What GoCommerce does not have yet The argument above is about engines in general. This is about this one. No store we know of runs GoCommerce in production yet. It carries over 1,000 tests, a documented contract for every route and the engine behaviour described on this page — but not production mileage, which only time and real stores provide. Build on it deliberately, and test your own store against it before it takes real orders. There is no hosted version, no paid tier and no support contract. You run it; help comes from the [issue tracker](https://github.com/itswadesh/gocommerce/issues) and the [Discord](https://discord.gg/GgdAeccwDR). Svelte Commerce runs arialshop.com in production, against a different backend. Its GoCommerce connector is [early, at 0.1.0](https://kitcommerce.store/gocommerce-svelte-commerce-connector/), and no store we know of runs the pair in production. A GoCommerce storefront built on it, or written against the API, is the experience layer — exactly the work this page says to hand an agent. FAQ ### Questions about vibe-coding commerce **Can’t an AI coding agent just write the commerce engine?** It can write one that works in a demo, and quickly. The argument here is about which mistakes you find, and when. A storefront bug shows on the screen the day it ships. An oversold unit, a discount rounded the wrong way or a webhook handled twice shows up later, in a reconciliation, as money that is not where it should be. That is the layer worth building against something written and tested in advance. **So an agent should never change GoCommerce itself?** It can, and the repository is set up for it. GoCommerce is MIT and meant to be modified: AGENTS.md holds 14 architectural rules and 4 notes for AI agents, skills/ holds 15 task guides, and over 1,000 tests run against a real PostgreSQL to catch a wrong edit. The difference is between changing an engine whose rules are written down and whose behaviour is tested, and improvising one that has neither. **Can I vibe-code a Svelte Commerce storefront against GoCommerce today?** Yes, through an early connector — Svelte Commerce’s GoCommerce connector is at 0.1.0 and covers catalogue, cart, checkout and order lookup; customer accounts and search are not covered yet. Svelte Commerce also runs against 26 other backends, and a GoCommerce storefront can instead be one you write against the documented API. That is experience-layer work: visible, testable in a browser and easy to throw away, which is exactly the work this page suggests handing to an agent. **Can AI shopping agents buy from a GoCommerce store?** Not through an agentic commerce protocol: ACP, UCP and AP2 are not supported. The MCP module is for running a store, not shopping in one — it inherits admin authentication, and its 19 tools read and change orders, stock, products, prices and discounts. A buying agent can use the same public catalogue, cart and checkout routes a storefront does, and building that entry point is experience-layer work. **Is GoCommerce ready for production?** No store we know of runs it in production yet. It has over 1,000 tests and a documented contract for every route, but not production mileage. Treat it as something to build on deliberately, and test your own store against it before it takes real orders. There is no hosted version, no paid tier and no support contract; you run it. **Does GoCommerce make me PCI compliant?** GoCommerce makes no compliance claim. What its Stripe and Razorpay modules do is keep card entry on the provider’s side: the engine creates a payment with the provider and hands the storefront what it needs to finish it there, and neither module asks the engine to handle a card number. Your compliance position depends on your provider and on how your storefront is built — ask your provider what applies to you. ### Let the agent build what the shopper sees One command gives you GoCommerce, its admin and its OpenAPI contract on a machine you control. Hand your agent `/docs` and a storefront to build; leave the ledger to the engine. [Deploy in minutes](https://kitcommerce.store/#one-command) · [Open source](https://kitcommerce.store/open-source/) · [Explore GoCommerce](https://kitcommerce.store/gocommerce/)