Build a branded catalog for an account, price it, take orders and quote requests, publish the customer-facing site, and hand new orders to a workflow.
Each account gets its own storefront, and a product belongs to exactly one of them, so pricing can differ per account with no cross-visibility. Branding covers store name, short description, logo text, primary and secondary color, background style, logo and banner images, contact phone and email, a display-only custom domain, and a welcome message shown above the catalog.
Duplicate a storefront to stand up a second account with the same catalog. Archive removes a storefront from circulation without deleting its order history; restore brings it back.
An optional access gate puts a shared code in front of the catalog. It keeps a published storefront out of casual view and is not authentication or account security — do not publish anything genuinely confidential behind it.
Categories come from a seeded library: business cards, flyers, postcards, brochures, booklets, posters, banners, labels and stickers, menus, mounted boards, packaging, and custom quote. A category with no products in a storefront does not render for the customer.
A product carries a name, category, description, base unit price, delivery fee, pickup and delivery permissions, and an active flag. Catalog artwork is a locally drawn icon by default; an uploaded PNG, JPEG, WEBP or SVG up to 700KB replaces it, and removing that upload restores the icon.
The customer estimate is assembled in four stages: quantity price breaks resolve the unit price (the highest tier whose minimum quantity is met wins, and the base unit price applies below the lowest tier); configurator option choices add a per-unit price delta; the selected turnaround adds a percentage surcharge on the subtotal; and a flat delivery fee applies when delivery is chosen. New products start with Standard, Expedited (+20%) and Rush (+45%) turnaround options.
The operator preview, the customer configurator and the published site all run the same pricing code, so one configuration produces one price everywhere.
Preview storefront runs the published experience inside the application: the access gate when enabled, then the catalog with search and category filtering, then the configurator with options, quantity, turnaround, pickup or delivery, job name, PO number, notes and an artwork upload against a live estimate, then the basket, checkout details, and confirmation. A custom quote product collects the same details without a price and arrives as a quote request. Exit preview returns to admin mode.
Orders placed in preview are real rows in the queue, which makes preview the practical way to rehearse a catalog before publishing it.
Orders and quote requests are tabbed by status with live counts, and searchable by order number, customer and company. The status sequence is New, Needs artwork, Ready, In production, Complete. An order records the customer, configured lines, estimate, delivery method and address, job name, PO, due date and uploaded artwork; notes can be added at any point and status changes are recorded against the order. Quote requests use the same vocabulary on their own tab.
All products and All orders list every product and every order across all storefronts. A product can be assigned as an independent copy to another storefront, so repricing it for the new account does not affect the original.
Publishing generates a self-contained static site — one HTML file, the product images and the pricing logic — reproducing the customer preview with no build step. Publish to GitHub Pages with a classic GitHub token carrying repo scope and a repo name of letters, numbers and hyphens; publish to Netlify with a Netlify token and a site name of lowercase letters, numbers and hyphens. Tokens are saved once for the application rather than per storefront and can be replaced at any time.
After a successful publish the live URL is retained with its publish date. Publishing again overwrites the site with the current catalog, which is how a price change reaches customers.
The default is None (email request): the customer submits, the order lands in the queue, and payment is handled outside the storefront. Stripe collects payment at checkout and requires the publishable key (starts with pk_) in the storefront, the secret key (starts with sk_) saved encrypted on the workstation, and STRIPE_SECRET_KEY set as an environment variable on the published Netlify site.
A storefront can hand every new order and quote request to a published Automation Workflow the moment it is placed. The job is the customer's artwork itself, so preflight, imposition and delivery steps have real files to work on. The commercial ticket travels with it as job variables — storefront and order number, customer name, company, email and phone, product, category, quantity and total, job name, PO, due date, turnaround, delivery method and address, customer notes, the attached artwork's name, and one variable per configurator group so a workflow can select the imposition template that matches the stock the customer chose. Quote requests add project name, description, desired quantity, dimensions and finishing notes. These jobs arrive with the trigger storefront-order.
The run reports back onto the order rather than only into the workflow log. Each sent order carries an Automation workflow panel showing the workflow, the run state, the file count and the last thing the run reported, and every change is written to the order timeline. A run that starts, or that stops to wait for an approval, is reported without changing the order status. A run that finishes cleanly moves the order to Ready. A run whose preflight failed moves it to Needs artwork and records the reason. A run that fails for any other reason — an unreachable output folder, a full disk — is recorded but leaves the status alone, because that is not an artwork problem. A workflow only ever advances an order out of New or Needs artwork, so a status an operator set by hand is never overwritten.
The same panel sends an order to a workflow by hand: use it to re-run after the customer supplies corrected artwork, to send an order placed before automation was enabled, or to run a different workflow than the storefront's usual one. Each send starts a fresh run and files the previous one under earlier runs.
Workflows must be published before they appear in the selection list.