Conversion is an engineering problem
Conversion work that matters isn't a theme tweak — it's latency budgets, catalog integrity, and failure states. An argument for treating conversion as infrastructure.
The three real levers
Speed, as a budget not a vibe. Every template has a performance budget — and budgets only hold when someone treats regressions like bugs. A product page that renders fast on the store's worst device and worst network, every time, is an engineering artifact.
Catalog integrity. Customers don't distinguish between "the site" and "the data." A product with a missing size chart, a stale price, or vague availability isn't a data issue — it's a lost order with extra steps. The catalog spine — fields, naming, media, feeds — determines what every downstream surface can even promise.
Failure states. Out of stock. Payment declined. Address validation failed. These moments are where purchase intent actually dies, and they are built by engineers. A store that handles its failure states honestly — clear message, clear next step, cart intact — converts better than one that only designed the happy path.
What this means for how stores get built
It means conversion decisions belong in the architecture phase, not the post-launch "optimization" phase:
- Performance budgets set per template, enforced in review.
- Product data modeled once, properly, with storefront/feeds/integrations reading from the same source of truth.
- Error, empty, and edge states designed and built alongside the happy path — not found in analytics later.
The uncomfortable summary
Most of what gets A/B tested on a struggling store is downstream of decisions the theme can't fix. If the foundation is slow, the catalog is inconsistent, and failure states are an afterthought, you are testing button colors on a machine that's already decided.
Build conversion as infrastructure. Then the experiments have something solid to stand on.