What does an online store need first?

Product catalog and variants, inventory with no overselling, cart, idempotent checkout, payments and webhook-written payment state and order lifecycle. The plan for a online store covers all of these before it generates code.

What should I leave out of the first version of an online store?

No storing card data or building a custom payment form. No multi-vendor marketplace payouts (see marketplace). No multi-warehouse routing, subscriptions or B2B price lists in phase 1.

Which products define the online store category?

Well-known examples include Shopify storefronts, Amazon, Allbirds, Gymshark and Etsy shops. Use them to decide which features your users expect, then describe your own version.

All app types

Build an online store

How to build an online store with AI

To build an online store, describe who it is for and what they do in it, and let Forge64 plan and generate the app. A single-merchant online store: product catalog with variants and media, inventory that never oversells, cart and idempotent checkout, order lifecycle, taxes and shipping hooks, discount codes, the payment provider payments with webhook-written payment state, faceted search and a fast image-optimised storefront. The core parts of a first version are product catalog and variants, inventory with no overselling, cart, idempotent checkout and payments and webhook-written payment state.

Last checked October 22, 2026

What the first version needs

These are the parts a online store needs before it is useful. Each one is something the plan covers.

Product catalog and variants: Products with options (size, color), per-variant SKU, price and media, organised into collections.
Inventory with no overselling: Guarantee a unit is never sold twice, even under a flash-sale stampede.
Cart: Hold intent to buy across sessions and devices without holding stock.
Idempotent checkout: Turn a cart into exactly one order and one payment, however many times the buyer clicks.
Payments and webhook-written payment state: Take payment safely and never mark an order paid from a browser redirect.
Order lifecycle: A single auditable state machine from pending to delivered, including cancellation and returns.
Taxes, shipping and discounts: Correct totals with pluggable tax and shipping providers and safe promotions.
Search and facets: Find products by text and filter by price, option, availability and collection.
Image pipeline and CDN: Fast, light product imagery so the storefront converts on mobile.

Parts you can add in the first version

Fulfilment and notifications: Mark shipped with tracking, email the customer, support returns and refunds.
Merchant admin and reports: Manage catalog, stock, orders, discounts and see sales.

The data it stores

Each table below becomes part of the Postgres database that belongs to your app.

products: status: draft|active|archived; min_price_cents is denormalised from variants for cheap sorting; search column maintained by trigger.
product_variants: options example {size:'M', color:'Black'}; price is the only price source, cart and order lines are snapshots.
product_media: alt text required for accessibility; renditions derive from object_key by naming convention.
collections: kind: manual|automated; automated rules materialise into collection_products by a job.
collection_products: join table, bounded by the number of products.
inventory_levels: CHECK (on_hand >= 0 AND reserved >= 0 AND reserved <= on_hand) is the database-level last line against overselling; available = on_hand - reserved.
inventory_reservations: status: active|committed|released; released rows decrement inventory_levels.reserved exactly once guarded by the status predicate.
inventory_movements: append-only ledger of on_hand changes: received, sold, returned, adjusted; reconciles to inventory_levels.
carts: status: open|converted|abandoned; anonymous carts expire after 30 days of inactivity.

Pages and endpoints

Routes in a first version of an online store
Route	Who can use it	What it does
/	public	home with featured collections, ISR with tag revalidation.
/collections/[handle]	public	collection grid with filters and cursor pagination, edge cached.
/products/[handle]	public	product detail, variant picker, live availability from a small uncached read.
/cart	public	cart review, re-priced server-side on each load.
/checkout	public	address, shipping and discount review before redirect to hosted payment.
/orders/[number]	authed	order status, tracking, returns; guest access by signed lookup token.
/account/orders	authed	order history, keyset paginated.
/api/cart/items	public	add, update and remove lines; quantity and line caps, rate limited.
/api/checkout	public	idempotent order creation, atomic inventory reserve, payment session.
/api/discounts/validate	public	validate a code against the cart, rate limited per IP to stop code guessing.
/api/media/presign	internal	merchant image upload URLs with type and size limits.

What to leave out of version one

No storing card data or building a custom payment form.
No multi-vendor marketplace payouts (see marketplace).
No multi-warehouse routing, subscriptions or B2B price lists in phase 1.
No client-trusted prices, totals or stock levels.
Reviews and recommendations: plan for it, build it later.
Multi-location inventory, subscriptions, B2B pricing: plan for it, build it later.

How Forge64 builds it

Forge64 matches your description to one of 12 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as email, background jobs, file uploads and search are coming soon, so anything here that needs them is something you add yourself for now.

FAQ

What does an online store need first?: Product catalog and variants, inventory with no overselling, cart, idempotent checkout, payments and webhook-written payment state and order lifecycle. The plan for a online store covers all of these before it generates code.
What should I leave out of the first version of an online store?: No storing card data or building a custom payment form. No multi-vendor marketplace payouts (see marketplace). No multi-warehouse routing, subscriptions or B2B price lists in phase 1.
Which products define the online store category?: Well-known examples include Shopify storefronts, Amazon, Allbirds, Gymshark and Etsy shops. Use them to decide which features your users expect, then describe your own version.

Build your app with Forge64

One prompt to a running app with auth, database, hosting and payments. Start free, no credit card required.

Start building for free