Shopfront
A real store: cart checkout with Stripe, inventory that can’t double-decrement, and confirmation emails sent exactly once.
What was asked for
This is the specification the app was generated from — one prompt, published in full and unedited, rather than a summary of it.
Build an online store app for a single business. The business owner signs in with operator credentials configured in the environment — there is no owner signup page. The owner manages the store's catalog: each item has a name, a description, a price, one or more photos the owner uploads, and a stock count. The owner can add stock to any item at any time. Customers do not need an account. They browse a visual grid of the items with photos and prices. An item whose stock is zero is shown grayed out as sold out and cannot be purchased. Customers add items to a cart, choosing a quantity for each, and check out the whole cart in one payment through a secure hosted checkout page. At checkout the customer provides their email address and their shipping address. Checkout must not go through for a quantity larger than an item's available stock, and sold-out items can't be checked out at all — the stock rules are enforced by the server, not just the page. When an order's payment completes, exactly once: each purchased item's stock goes down by the quantity bought (an item that reaches zero becomes sold out), the order is recorded with its items, quantities, the customer's email, and the shipping address, and a confirmation email listing the order's contents and shipping address is sent from the store's own email address to both the customer and the business owner. A duplicate or replayed payment notification must not decrement stock twice or send the emails twice. The owner has an orders page listing orders newest-first with their items, quantities, shipping details, and payment status, and gets a notification when a new order arrives.
What got built
- Stripe checkout
- Order emails
- Inventory integrity
- Owner admin
- Media
Things you can actually do in it
The app is live and public. Without taking our word for anything, you can:
- Add 2 of an item with stock 3 to your cart and check out with the Stripe test card
- Stock drops to 1 and two confirmation emails go out — customer and owner
- Buy the last unit — the card grays out "Sold out"; the server enforces stock, not the page
- Replayed payment webhooks can’t decrement stock twice or double-send email
The code
The repositories are public: a Deno backend carrying the generated test suite, the OpenAPI spec and a Dockerfile, and a React frontend built against that same spec. This is the export a build hands you — clone it and read it.
Every one of them has exactly one commit: "Initial export from ConceptualAI". Nothing has been hand-fixed after the fact, and you do not have to take our word for that — the commit history is public, and a second commit would be sitting right there if we had.
Why this one is here
It has a real backend
Authentication, persisted data, and the integrations above are running server-side against a real database — not mocked, and not a frontend pretending.
Its tests are in the repository
The concepts underneath — data, auth, the state everything else depends on — are accepted only once their generated tests pass against a real database. Those tests shipped with the code, so you can run them yourself.
It runs without us
No proprietary runtime and no SDK in between. Clone the backend and it runs anywhere a container runs.
You would own this one
An equivalent build hands you both repositories on any plan — Free included, once you have the three credits a minimum build costs. See pricing.
Build something like this
If this looks like the thing you are trying to build, describe yours in the builder. If it looks like less than what you need, our honest comparison covers when an app builder or a development shop is the better call.