Example build / Test-mode homeware store
A purchase system, not a generated product grid
The proof begins after the Add to cart button: server-calculated prices, inventory limits, hosted checkout, signed events, idempotent orders, and private administration.
Products, carts, inventory, and orders need durable state through managed databases for ecommerce data.
Catalog
Products, variants, prices, and availability.
Cart
Server-verified totals and stock limits.
Checkout
Hosted provider flow in test mode.
Orders
Signed events create each order once.
Before you prompt
Make the commercial decisions before generating checkout
Code cannot decide where you sell, how you calculate tax, what shipping costs, or which returns you accept. Record those decisions—or mark them unresolved—before the agent touches payments.
Product truth
Define products, variants, prices, currency, inventory rules, and which source owns each value.
Fulfilment boundary
Write down shipping countries, rates, delivery promises, stock behavior, and support contact.
Payment boundary
Use hosted checkout and provider test mode. Never collect or store raw card details in the app.
Customer obligations
Confirm tax, refunds, returns, privacy, terms, prohibited products, and support before going live.
A store is a full-stack app. If this is your first build, complete build your first app with AI before adding money and customer data.
Policies before payment
Plan the complete test purchase and its business boundaries
Fill in each field with a real decision or write 'decision needed.' The agent must surface missing tax, shipping, refund, privacy, and provider requirements before editing.
Help me plan a small online store in this Adios workspace. Do not edit files yet.
Store facts:
- Store name: [NAME]
- Customer: [CUSTOMER]
- Product types: [PRODUCTS]
- Variants: [SIZE, COLOR, OR OTHER OPTIONS]
- Inventory rule: [TRACKED, MADE TO ORDER, OR NOT TRACKED]
- Countries served: [COUNTRIES]
- Currency: [CURRENCY]
- Payment provider: [PROVIDER IN TEST MODE]
- Shipping approach: [RULE]
- Tax approach: [RULE OR DECISION STILL NEEDED]
- Refund and return policy: [REAL POLICY OR DECISION STILL NEEDED]
Inspect the repository, database setup, authentication, tests, health route, and adios.yaml. Plan the smallest end-to-end test store covering catalog, product detail, cart, checkout handoff, signed payment events, orders, inventory, and protected administration.
List decisions I still need to make about tax, shipping, refunds, privacy, customer support, prohibited products, and payment-provider requirements. Wait for my approval before editing.What a useful response contains
- A complete test purchase journey
- Authoritative product, price, and inventory sources
- Order and payment state transitions
- A list of unresolved business decisions
Build in test mode
Generate the catalog, cart, checkout handoff, and order state
This prompt keeps price calculations on the server, uses hosted checkout, verifies signed events, and makes duplicate-event tests part of the build.
Build the approved online-store test version. Do not enable live payments or deploy to production.
Requirements:
- Preserve the current framework, package manager, health route, tests, and Adios deployment files.
- Store products, variants, inventory, carts, and orders in the configured database with clear relationships and reversible migrations where supported.
- Calculate prices and inventory on the server. Do not trust totals sent by the browser.
- Use the payment provider's current official SDK and hosted test checkout. Never collect or store raw card details.
- Verify signed webhooks, handle duplicate events idempotently, and record a clear order-state history.
- Protect administration routes and enforce permissions on the server.
- Keep payment, database, email, and session secrets out of source and list their environment-variable names.
- Add useful loading, empty-cart, sold-out, declined-payment, cancelled-checkout, and order-confirmation states.
- Use sample products clearly labelled as fictional. Do not invent reviews, scarcity, discounts, certifications, or delivery promises.
- Add tests for price calculation, inventory limits, authorization, webhook signature rejection, duplicate events, and the order happy path.
- Run the existing formatter, lint, tests, and production build.
Return the changed files, data model, order-state model, test evidence, required Adios secrets, and an exact Preview test journey. Do not deploy.What a useful response contains
- Server-owned totals and inventory
- Hosted provider checkout in test mode
- Verified, idempotent payment events
- Protected administration and private orders
Exercise failure and replay
Audit the purchase journey beyond successful checkout
The useful tests are declined, cancelled, tampered, duplicated, unauthorized, and out of stock. This prompt asks for evidence for each one.
Audit the store's complete test-mode purchase journey. Fix only confirmed problems and do not deploy.
Test:
- browsing products and selecting valid variants;
- price, currency, quantity, and inventory calculations;
- empty, expired, tampered, and out-of-stock carts;
- successful, declined, cancelled, and repeated checkout events;
- invalid webhook signatures and duplicate valid webhooks;
- order creation and inventory updates occurring exactly once;
- a customer being unable to access another customer's private order;
- an unauthenticated user being unable to access administration;
- logs avoiding card data, credentials, and unnecessary personal information; and
- formatter, lint, tests, build, and health checks.
Give me a result for every case, remaining risks, and the manual steps I must perform with the provider's test tools.What a useful response contains
- A recorded result for each failure path
- Exactly-once order and inventory behavior
- Private customer and administration access
- Provider test-tool instructions
Separate code from obligations
Prepare a production-readiness decision without going live
The last prompt distinguishes technical evidence from tax, fulfilment, privacy, support, and policy choices only the store owner can approve.
Prepare this store for a production-readiness decision. Do not switch to live payment credentials and do not deploy.
Confirm the production domain, product and price source of truth, currency, inventory behavior, shipping regions and rates, tax decision, refund policy, privacy notice, terms, support contact, order emails, webhook URL, secret names, database migration, backups, health route, logs, and rollback plan.
Separate technical checks that passed from business or legal decisions I still own. List every test-mode value and placeholder that must be replaced. Stop for explicit approval before any live payment or production change.What a useful response contains
- Technical evidence separated from owner decisions
- Every test-mode value and placeholder listed
- Migration, backup, webhook, health, and rollback notes
- No live credential or deployment change
Test the result
A passing build is the start of the review
Open Preview and perform the important journeys yourself. Ask the agent for evidence, but do not confuse its summary with your approval.
Money and stock
- The server recalculates price, currency, quantity, discounts, and stock before checkout.
- Empty, expired, tampered, and out-of-stock carts fail with a useful next step.
- A valid payment event creates the order and inventory movement exactly once.
Payment events
- Invalid signatures are rejected and duplicate valid webhooks are harmless.
- Successful, declined, cancelled, delayed, and repeated test events have explicit results.
- No raw card data, provider secret, or unnecessary personal data enters source or logs.
Access and operations
- Customers cannot read another customer's private order and strangers cannot open administration.
- Migrations, backups, order email, health, logs, and rollback behavior are known.
- Tax, shipping, refund, privacy, terms, support, and product obligations have an owner decision.
Human approval gate
Keep the store in test mode until every gate has an owner
This guide intentionally stops before live payments. Complete the provider test journey, settle the business and legal decisions, replace every test value, and obtain explicit approval before indexing or releasing the store guide as proven.
host and deploy the finished AI-built store- 01Record successful, declined, cancelled, duplicate, invalid-signature, and out-of-stock tests.
- 02Confirm orders and inventory change exactly once and private routes enforce ownership.
- 03Resolve tax, shipping, refunds, privacy, terms, support, email, backup, and rollback decisions.
- 04List and replace every test-mode ID, URL, credential name, and content placeholder.
- 05Approve live-payment and production changes separately; do not infer approval from a passing build.
Questions before you start
What this guide does—and does not—promise
Can AI build a working online store rather than a mockup?
It can help generate a working custom store, but the proof includes server-side pricing, inventory, hosted checkout, signed events, idempotent orders, protected data, tests, and real policies. A product grid and cart animation are not enough.
Why does the guide require hosted checkout?
Hosted checkout keeps raw card collection with the payment provider rather than your application. The app still must protect provider secrets, verify signed events, handle repeats safely, and own order state correctly.
Who is responsible for tax, shipping, refunds, and privacy?
The store owner remains responsible for those business and legal decisions. The AI can implement approved rules and surface missing choices, but it cannot decide which obligations apply or approve them for you.
Why is this page not indexed yet?
Adios will index the guide only after its example completes the entire test-mode catalog, checkout, webhook, order, inventory, authorization, and failure workflow. That gate prevents an unverified commerce promise from being published as proof.