Blueprint
E-commerce Store
Selling physical products, and the question worth asking before you do.
This is the one blueprint where I am handing you insight rather than experience. I do not build many of these and I do not particularly want to. One Shopify store a while back, WooCommerce enough times to know exactly what it is, and plenty of taking money in other ways. What I have is the pattern and the questions, not a portfolio of storefronts. I get asked about it constantly, so here is the honest version.
Start with the question most people skip: are you actually building an e-commerce store? Plenty of people asking for one are not selling a physical thing at all. They want to sell a course, a template, a subscription, access to something. That is not a store, it is a website with a checkout, and treating it like a store costs months.
If you are genuinely shipping physical goods, the honest answer is a platform until you have a specific reason not to. The three tracks below are the same question asked in order: what are you actually selling, what already solves it, and what you take on the day you decide to leave.
If what you are selling is digital, you probably do not need a store. Put the products and prices in Stripe, put Checkout on a static site, and let a serverless function deliver the file. That is the Marketing Website blueprint with a buy button, and it skips every hard part below, because there is no stock to count and nothing to ship.
What that actually looks like
The catalog and the checkout
Products, prices, and the payment page all live in Stripe. You are not building a cart, you are linking to one.
The site around it
An ordinary static site. Nothing about selling a digital product requires a different kind of website.
Delivering the thing
A function listens for the payment and emails a signed link. That is the entire fulfilment system.
I do not particularly like Shopify. It is closed, you rent it, and you are building inside somebody else's box. Use it anyway. Physical goods drag along a set of problems that have nothing to do with building a website, they have solved every one of them, and choosing otherwise means a much harder life to prove a point. I am not paid by them and I do not have an account.
The problems they have already solved
Sales tax, everywhere you sell
Applies rooftop-accurate US rates at checkout. Nexus rules differ by state and keep changing, and this is a compliance problem rather than a coding one.
Shipping rates and labels
Live carrier rates, printed labels, and tracking that reaches the customer without you touching it.
Stock that can't oversell
No separate product, it is just there. Stock deducts as orders are placed, across locations. Two people reaching for the last item is the hard case and it is already handled.
Fraud and chargebacks
Reimburses eligible fraud chargebacks, though only on qualifying Shop Pay orders, so read the terms. The wider point stands: somebody else is fighting this.
Card data and PCI
The native gateway, so card data never touches a server you are responsible for and you are not shopping for a merchant account.
Returns, refunds, abandoned carts
Returns and exchanges run from the Orders page. Unglamorous, constant, and the real reason storefronts get bought instead of built.
There are two honest roads out and the fork is whether it is still a store. If it is, just bigger or stranger, most people move to Shopify Plus or WooCommerce, and there is a whole industry making WooCommerce work at scale. I would not build that one. It is a plugin stack on a server you now own and patch, and I have used it enough times to be sure. But it exists and pretending otherwise would be dishonest. Custom is the other road, and it is right when the store has stopped being a store and become part of how the business runs. At least one trigger below should be true, and notice the stack is the Web App blueprint with a payment layer on it.
Reasons you'd actually be here
Pricing per customer
Different buyers see different prices, with rules behind them rather than a discount code.
Products that get configured
Not a variant dropdown. Options that change price, stock, and lead time.
Physical plus recurring
A subscription and a shipped good living in the same account.
Stock that lives elsewhere
The platform is no longer the source of truth, and fighting that is expensive.
Fees at volume
Per-transaction cost stops being trivial once the revenue is real.
What you take on when you leave
Framework
Needs a server: carts, checkout sessions, and webhooks.
Catalog, inventory, orders
Postgres. Stock comes down inside a transaction rather than in app code, or you will oversell.
Payments
Hosted or embedded, so card details never touch your server.
Sales tax
The thing you were getting for free, now bought back deliberately.
Order of record
The order is created when the webhook fires, never on the thank-you page. Connections drop and people close tabs.
Host / deploy
Same as any other app on this site.
Shipping and fulfilment
Rates, labels, tracking, returns. None of it arrives with the framework, and this is the part that quietly sinks custom builds.