A Shopify store that passes your visual review can still have problems that don't show up until a real customer hits a specific product, a specific cart state, or a specific screen size you didn't test on.

Pre-launch QA on a Shopify build is harder than it looks from the outside. There are a lot of surfaces: the theme templates, the section schemas, the JavaScript, the metafield logic, the checkout customizations, the mobile layout at every breakpoint, the structured data markup that search engines read. A two-person studio doing a thorough manual review will catch most things. "Most" is not good enough when a missed issue is the reason a customer abandons checkout.

This post is about how we added Claude Opus 4.8 to that review process, what it actually finds, and what it doesn't replace. If you're running your own Shopify store or working with a developer, there are things in here worth knowing regardless of whether you hire us.

Why Liquid templates specifically

Shopify's Liquid templating language is straightforward when the logic is simple. It gets more complex when you layer in: multiple product types with different metafield configurations, conditional sections that render differently based on tags or collections, cart transforms, dynamic checkout buttons, and theme blocks that can be combined in ways the original developer didn't fully test.

The problem isn't that Liquid is hard to write. The problem is that bugs in Liquid often don't produce obvious errors. Instead of a crash, you get a section that silently renders empty content. A conditional that evaluates to false when it should be true. An image that loads without its alt text because a fallback wasn't handled. A price display that shows "0.00" on a product variant with a specific metafield configuration.

These are the kinds of issues that survive manual review because the reviewer tests the normal path and the layout looks correct. The edge case only surfaces later.

What we actually do: feeding the templates to Claude Opus 4.8

The model we use for this is Claude Opus 4.8. We use it for code-level work specifically — Anthropic's documentation and testing shows it is significantly less likely to miss code issues than its predecessors, and in practice it asks clarifying questions and flags uncertainty rather than guessing. For a QA pass, that matters more than speed.

The process is direct. We paste the relevant Liquid templates into a session and give the model a structured brief: what the store sells, what metafields and custom data are in use, which sections have conditional logic, and what the expected behavior should be at each step of the customer journey.

Then we ask it to work through the templates as a QA reviewer and flag anything that looks wrong, incomplete, or likely to break under a non-standard condition.

Here is the kind of output that comes back.

The issues it actually finds

Empty output from unhandled null metafields

A product detail page renders a specifications block using a product metafield. The Liquid correctly checks whether the metafield exists before rendering the section heading — but doesn't check whether the metafield's value is empty. On products where the metafield exists but has no value assigned, the section renders with a heading and no content beneath it. To a visual reviewer, the product looked fine because the test products all had data filled in.

The fix is a single additional conditional. But it only gets caught if you review the template against the data, not just against the visual output.

Missing alt attributes on dynamic images

A collection page template pulls images from a metafield and outputs them as a gallery. The alt text for each image is also pulled from a metafield. If the alt text metafield is empty, the alt attribute is output as blank. The images are present, but they have no descriptive alt text. This is both an accessibility issue and, on product images, a mild SEO problem.

Again: the page looks correct in a visual review. The issue is invisible until you inspect the HTML or run an accessibility audit.

JavaScript that runs before DOM elements are ready

A theme customization uses a script to initialize a product variant picker. The script runs on DOMContentLoaded. On slower mobile connections, depending on how the theme loads assets, the target element is occasionally not yet in the DOM when the script fires. The result is a variant picker that works in desktop testing but intermittently fails on real mobile devices under realistic network conditions.

This is the hardest class of issue to catch manually because it doesn't reproduce reliably on a fast development machine. The model flagged it by recognizing the pattern in the code — not by testing the behavior.

Checkout edge case: gift card and discount code conflict

A store was configured to allow both gift card redemptions and discount code applications at checkout. The Shopify checkout handles this natively, but the theme's cart drawer was displaying a misleading total before the customer reached checkout — showing the discount as applied when it hadn't actually been validated yet. A customer with a gift card balance would see a confusing number before landing on the real checkout total.

Not a broken checkout. But a confusing one, which is almost as bad.

JSON-LD structured data errors

The theme included schema markup for products — this is the structured data that powers rich results in Google Search. The markup was using a metafield for the product's availability status. On pre-order products, the metafield value wasn't mapping to a valid ItemAvailability enum. Google's rich results test would reject the markup for those products, meaning the store wouldn't get rich snippets for its pre-order inventory.

What the model does not replace

The AI pass does not replace the manual review. It runs after it — or alongside it — not instead of it.

There are things it doesn't do well:

It cannot test actual behavior. It reads code and reasons about what should happen. It cannot load the store in a real browser, add a product to cart, and observe the checkout flow. Human testing on real devices with real network conditions is not optional.

It does not know your business logic. If your store has a specific rule — free shipping above a certain order value, a custom discount logic, a subscription product that behaves differently — you have to brief the model on that context. It cannot infer it from the code alone.

It misses visual problems entirely. Fonts loading incorrectly, image proportions that are off, spacing that looks wrong on a specific screen size — these require eyes on the actual rendered page.

It generates false positives. Not everything it flags is a real problem. Every item in the report gets reviewed by us before it becomes an action item. The model is a first pass, not a final verdict.

Running your own Shopify QA: what to look for

If you're reviewing your own Shopify store before launch — or reviewing a developer's work — here's a practical list of things worth checking manually, regardless of whether you use any AI tooling:

Metafield handling: for every metafield your theme uses, test what happens when that metafield has no value. The page should degrade gracefully, not render empty blocks or broken markup.

Image alt text: inspect the HTML source on your product and collection pages. Every <img> tag should have a descriptive alt attribute. Blank or missing alt text is both an accessibility failure and a missed SEO signal.

Mobile checkout path: run through the full checkout on a real phone on a real mobile network, not on a desktop browser with a mobile viewport. The differences are significant.

Structured data: use Google's Rich Results Test on your product URLs. Invalid schema markup is common and invisible until you test it.

Cart and discount interactions: test your discount codes with edge cases — stacked discounts if you allow them, expired codes, codes on ineligible products, codes applied from a mobile device. The cart drawer and the checkout page should show consistent numbers.

Variant edge cases: test every product variant combination you sell. Missing price, blank image slot, out-of-stock state that doesn't render correctly — these are all common on stores with complex variant configurations.

What this means for projects we build

On every Shopify project we ship, the pre-launch checklist includes a structured AI review pass on the Liquid templates alongside our manual device testing. Issues found in that review are fixed before the store URL goes to the client.

The handover document includes a record of what was checked — so you know the work was done, and so whoever maintains the store later knows what edge cases were considered during the build.

If you're starting a new Shopify store or rebuilding an existing one, start a conversation with us. The first message costs nothing, and we'll tell you honestly whether your project fits our process.

— Muhammad Tahir, BrightWire
brightwire.studio

How AI Changed the Way We Do Pre-Launch Checks on Shopify Stores