Shoppers are asking AI what to buy.
They ask for the best thing for a specific job, get two or three names, and buy one. Having the better product does not win that moment — being readable, corroborated and confirmably in stock does.
What actually breaks in an online store
None of these are marketing problems. Every one of them is a place where a machine reading your store arrives at an answer you did not intend.
Three prices for the same product
What breaks: The product page says $48. The merchant feed still says $54 from the last sale. The structured data says something else again because an app wrote it. Availability drifts the same way — the page says in stock while the feed says out.
Why AI gets it wrong: An engine deciding whether to name your product has to be confident it exists at that price today. Three disagreeing sources is not a small data problem; it is a reason to recommend the competitor whose numbers agree.
Collection pages and product pages answering each other’s questions
What breaks: “Best waterproof boots for wide feet” is a comparison question, and it lands on a single product page that cannot compare anything. Meanwhile “Ridgeline Boot size 11” lands on a collection of forty items.
Why AI gets it wrong: A generative answer needs a source that addresses the question it was asked. A page that sells one item cannot answer a question about choosing between several, and a grid of forty cannot answer a question about one.
Reviews that exist but cannot be read
What breaks: Hundreds of genuine reviews, held inside a third-party app that renders them with JavaScript after the page loads, with no rating markup in the HTML at all.
Why AI gets it wrong: Corroboration is the strongest signal in a shopping answer, and this is corroboration the engine never sees. From the outside, a store with six hundred reviews in a widget looks exactly like a store with none.
A theme you cannot reach into
What breaks: The fix is obvious and the platform will not let you make it — markup the theme generates and does not expose, an app stack adding four seconds to a product page, a checkout flow you cannot touch.
Why AI gets it wrong: This one is not the engine misreading you. It is the ceiling on how far the work can go, and it is the honest reason some stores should move and most should not.
What the work covers
Some stores need the first three items and nothing else. A store being built from nothing needs all of it.
Product, offer and review structured data that matches the feed
Price, availability, identifiers and ratings declared in the markup, and reconciled against what the merchant feed says. One source of truth, asserted everywhere.
Collection and product architecture
Deciding which page owns which question, then making each page assert one thing clearly. This is the part that moves comparison queries, and it is mostly editorial work rather than technical.
The storefront itself
When a build is the right answer: a static store that loads in under a second, with Stripe Checkout handling payment. Stripe hosts the payment page, so card details never touch the site and PCI scope stays with them.
Fulfillment wiring
Print-on-demand or a fulfillment provider connected so an order becomes a shipment without anyone retyping it. For a small catalog this replaces most of what a platform back office is for.
Email capture and the list
The list is the asset that survives a platform change, an algorithm change and a bad quarter. Capture, tagging and the sequences that follow a first order.
One screen that tells you how the store is doing
Revenue and refunds from payments, behavior from analytics, fulfillment status, list growth — in one view, with every panel labeled with where its number came from. Knowing which system a figure came from is what makes it usable.
A launch path that does not require a bank account on day one
Payments can run in test mode from the first day of the build, on nothing but an email address, so the store is finished and demonstrable before the business paperwork is. Going live needs the legal entity, a tax ID and a business bank account — that is usually the long pole, and it is better found early than late.
We run one of these ourselves.
First, the disclosure: outrageousintrovert.com belongs to CiteWave’s founder. It is not a paying client and we are not going to dress it up as one.
It is an apparel store, and it came off Wix. What runs now is the architecture this page describes: a static storefront on Netlify, Stripe Checkout handling payment with prices looked up on the server rather than trusted from the browser, and a webhook that turns a paid order into a print-on-demand order without anyone retyping it. The catalog is generated from the fulfillment provider’s own API on every deploy, so the product data has exactly one source.
Before any of that, we did the thing every store owner is told to do. Every SEO field Wix hands you, filled in. Titles and descriptions rewritten, then rewritten again. Many hours spent getting it “just right” — and it went nowhere.
The lesson was not that the effort was wasted or that platform SEO is a con; we still do that work for clients every week, and on most sites it is the right answer. The lesson was narrower and more useful: the boxes a builder gives you are not the whole surface a machine reads. You can fill every one of them perfectly and still be invisible, because what decides the answer is sitting outside the part of the page you were allowed to touch. Knowing exactly where that line falls on each platform is the difference between fixing a store where it stands and telling someone honestly that it cannot be fixed there.
That is the whole argument for one source of truth, made at our own expense. We know what a duplicate SKU does, what happens when a product exists in one system and not another, and why matching on a product title instead of a SKU quietly breaks a storefront. Those are not opinions we read.
You should trust a self-owned project less than a real client result, and we would rather say so than pretend otherwise. In exchange, every claim above is one you can check by opening the store and buying something.
Shopify, honestly
We build stores that do what Shopify does, faster and with no platform fee. That is true, and it is not the whole answer. Here is the part most people selling you a custom build leave out.
Where Shopify genuinely wins
- Inventory and variants at scale. Hundreds of SKUs, sizes, colors and stock counts across locations. Rebuilding that well is a project in itself.
- Shipping and fulfillment rules. Rate tables, zones, labels, returns. Genuinely hard, genuinely solved.
- A product editor anyone can use. Staff add products without a developer. This is the honest gap in a custom build, and closing it means building an admin screen on purpose.
- Somebody else carries the platform. Security patches, uptime, compliance and an app for nearly everything.
Where it costs you
- Speed. The app stack that makes Shopify convenient is the same stack that puts seconds on a product page. Those seconds are conversions and crawl depth.
- Control of the markup. AEO is almost entirely a question of what a machine can read. A theme decides how much of that you are allowed to change.
- Fees, twice over. The monthly plan, and a surcharge on every order if you use any payment provider other than theirs.
- A design bounded by a theme. Every serious change starts with what the theme already assumed.
The fact that settles most of these arguments
Shopify Payments is built on Stripe. Going direct to Stripe is not switching payment providers — it is removing a layer between you and the one already processing your cards. It cuts the other way too: because Shopify charges a surcharge on orders taken through an outside gateway, bolting Stripe onto a Shopify store is the one combination that costs you money for nothing. Pick a side.
So which one are you?
Stay on Shopify if
You hold real inventory, run many SKUs and variants, have staff editing products daily, or ship on complex rules. Then the work is fixing what the theme lets us fix — and that is usually plenty.
Build instead if
You sell a handful of products, print on demand, or drop-ship, and what you actually need is to be found and cited rather than administered. Then the platform is overhead you are renting.
“Don’t I lose my dashboards?”
No — but the numbers live in more than one place, and knowing which to believe is the whole skill.
Payments are the books. Analytics is the behavior.
Stripe knows exactly what was charged, refunded and disputed. Analytics knows what people looked at and where they left. They will never agree, because ad blockers and browser privacy limits stop a share of real purchases from ever reaching analytics. Reconciling them is a waste of an afternoon; each answers a different question.
Promotions and incomplete checkouts already live in payments
Promotion codes, how often each was used, and every checkout that was started and not finished — including the email address, where one was entered. That is not a platform feature. It is in Stripe.
“Abandoned cart” is two different questions
How big is the problem, and who do I email? Analytics answers the first because it sees everyone who browsed. Payments answers the second because it has the addresses. A tool claiming to do both is doing one of them badly.
Questions from store owners
Do I have to leave Shopify to work with you?
No. Most of this work happens on the store you already run. Shopify exposes a good deal of its markup to a theme, and schema, speed and collection architecture can be fixed inside it. We recommend moving only when the theme itself blocks the fix, or when the store is small enough that the platform is costing more than it returns.
Is a custom store really better than Shopify?
Better at some things, worse at others. A custom build is faster, gives complete control of the markup that answer engines read, and removes platform fees and the surcharge Shopify applies to outside payment gateways. Shopify is better at inventory and variants at scale, at shipping and fulfillment rules, and at giving a non-technical person a product editor. If you have hundreds of SKUs and staff editing them daily, stay on Shopify.
If I leave Shopify, am I switching payment providers?
Usually not. Shopify Payments is built on Stripe. Going direct removes a layer rather than changing who processes the card. It matters in the other direction too: Shopify charges a surcharge on every order that uses an outside gateway, which is why you should never bolt Stripe onto a Shopify store and keep both.
Do I lose my reporting if I am not on Shopify?
No, but it lives in more than one place. Stripe holds revenue, refunds, promotion codes and incomplete checkouts. Analytics holds behavior. The two will never agree, because ad blockers and privacy limits stop a share of purchases from reaching analytics. Payments are the books; analytics is the behavior.
Why would AI recommend one store over another?
Because it can confirm the answer. A product an engine can read clearly, whose price and availability agree across the site and the merchant feed, that carries readable reviews and sits on a page making one specific claim, is a product it can safely name. A product whose details contradict themselves is a risk it will not take when a competitor’s do not.
Further reading: Why isn’t my business showing up in AI answers? and What answer engine optimization actually is.
Find out what an AI assistant says about your products.
A store build starts at $7,000, and the diagnostic that decides whether you need one at all is $950. Most stores do not need rebuilding.
The diagnostic includes asking current AI tools the questions your buyers ask, and recording which stores get named. That is usually the part that lands.