A store’s front end is a public record of every decision its owner has made about the storefront. The theme they chose, the apps they installed, the payment methods they enabled, the carriers they offer — none of it is private, all of it is detectable, and taken together it tells you more about what a merchant will buy than any firmographic field ever could.
Most agencies pitching CRO or design open a store, form an aesthetic opinion, and write an email about it. That is a taste argument, and taste arguments lose. Reading the stack is a different exercise entirely: it produces observations the merchant cannot dismiss, because they are facts about their own choices rather than opinions about your preferences.
The app stack is a budget statement
Every installed app is a decision to spend money on a specific problem. Read the list and you get the merchant’s own priority ranking, written by them, without an interview and without a discovery call.
A store running a review app, a loyalty tool, a bundling app and an upsell widget has already accepted the premise that storefront optimisation is worth paying for. You are not selling them the category; you are selling a better version of something they have bought before. That is a dramatically shorter conversation, and it justifies a higher price than the same work sold to a sceptic.
A store running nothing but platform defaults is a different animal. They may be early, they may be philosophically opposed to bolted-on tools, or they may simply never have been shown the arithmetic. The pitch there is not a redesign — it is one number: what a small conversion improvement is worth against their current traffic. Sell the concept before you try to sell the work.
The most interesting signal is the incoherent stack: three apps doing overlapping things, a subscription tool on a store with no subscription products, a currency converter on a single-market store. Incoherence means accumulation without review, which means somebody bought tools instead of buying a strategy. That merchant is very often ready to pay for the strategy.
Reading a theme without starting a design argument
Theme detection gives you two things: which theme, and therefore what it can and cannot do without custom work; and whether the merchant sits on a default free theme, a paid theme, or something custom. Each implies a different budget and a different kind of pain.
A merchant on a heavily customised premium theme has already spent money on the storefront and probably has a developer relationship they value. Pitching a rebuild insults that investment. Pitching a series of targeted changes — the product page, the cart drawer, the mobile filter interaction — respects it, and is far easier to fund out of an existing budget line.
A merchant on a stock free theme with 800 products has a structural problem rather than a cosmetic one: they are running a large catalogue on a template designed for a small one. That is a navigation and merchandising conversation, and it sells much better than “your site looks dated”, because it names a consequence the merchant has almost certainly felt in their own analytics.
Cross the theme read with catalogue size and traffic and the segments fall out on their own. Large catalogue, basic theme, real traffic is the single best CRO prospect there is: enough volume for changes to be measurable, enough complexity that the template is genuinely in the way, and enough revenue to fund the work without a board meeting.
Payments and shipping are friction, made visible
Checkout is where CRO stops being theoretical, and two detectable fields tell you a surprising amount about it: which payment methods a store accepts, and which carriers it offers.
A store selling into a market where a particular local method dominates, without offering that method, is losing orders at the last step — and that is a fixable, arguable, revenue-shaped observation rather than an opinion about layout. The same logic applies to a store offering exactly one shipping option in a category where buyers expect choice, or no visible express option in a category where urgency drives the purchase.
These make excellent first emails precisely because they are narrow. “You accept two payment methods; stores in your category and country typically accept four or five, and the missing ones are the ones younger buyers default to” is specific, checkable, and entirely free of taste. It also opens naturally onto the wider conversation, because a merchant who concedes the checkout point will listen to the product page point.
Turning a stack read into a pitch
The shape that works is: observation, mechanism, arithmetic, small ask. The observation comes from the stack. The mechanism is the sentence explaining why that observation costs money. The arithmetic converts it into their currency. The small ask is anything at all except a demo.
An illustrative version, deliberately generic: “You have 1,200 products on a stock theme, and your category pages carry no filters beyond price. At your traffic level, category-page drop-off is usually the largest single leak in a catalogue that size. I mapped your top ten categories against the filters your buyers would expect — one page, attached.” There is no aesthetic claim anywhere in it.
Notice what is doing the work: catalogue size, theme, traffic, all detectable at scale across a database. You could send a version of that email to every store matching the pattern, and each one would be individually true. That is the difference between personalisation and mail merge, and merchants feel it immediately.
Which stacks are worth your time
Not every store is a CRO prospect, and the cheapest thing you can do is disqualify early. Traffic is the first filter: below a certain monthly volume, conversion work cannot be measured within any reasonable window, and you will spend the engagement arguing about noise. Sell those merchants acquisition, or a fixed-price redesign, but not optimisation with a promised uplift.
Catalogue size is the second filter. Small catalogues concentrate all their conversion pressure onto a handful of product pages; large catalogues leak in navigation, filtering and internal search. Same discipline, different work, different price — and pitching the wrong one earns you a polite no from a merchant who was actually a good fit for the other.
Platform is the third, and it constrains the work more than most agencies admit. Some platforms make checkout changes trivial; others make them impossible outside an enterprise plan. Across 60 platforms in the wild — WooCommerce and Shopify accounting for the largest share by a wide margin, then PrestaShop, then a long tail of regional builders — the practical answer is to pick one or two, get genuinely fast on them, and let the rest go to somebody else.
Retention tooling tells you what to sell second
The stack does not only tell you what to pitch today. It tells you what the merchant will be ready to buy in six months, which is how a one-off project turns into a relationship instead of a transaction.
A store with an email tool and a review app but nothing for loyalty, referrals or subscriptions is a store that has solved acquisition-adjacent problems and left the repeat-purchase side alone. That is not a criticism — it is a sequence. Once you have improved the product page and the merchant has seen the numbers move, the retention gap is the obvious next block of work, and you are the person who already has their data and their trust.
The inverse is just as useful. A store with heavy retention tooling and a weak product page is spending money to bring people back to an experience that did not convert them the first time. Stated in those terms, it is a very hard observation for a merchant to ignore, and it reframes your CRO work as protecting an investment they have already made rather than as a new line item.
How to shape the engagement
CRO sold as a monthly retainer with no defined output is the easiest service in the world to cancel. Sell a first block instead: a fixed-price engagement with a named surface — the product page, or the category and filter experience, or checkout — a defined number of changes, and a measurement plan agreed before anything ships.
The measurement plan is not optional, and it is where you protect yourself. Agree in writing what will be measured, over what window, and what counts as a result. On a store without the traffic to reach a clean read, say so plainly and price the work as a build rather than as an experiment. Merchants respect that far more than a promised percentage that quietly stops being discussed after month two.
Then the retainer becomes obvious rather than requested. Once the first surface is rebuilt and measured, the next one is the natural next purchase, and you now hold a before-and-after on their own store — the only case study that has ever really mattered to a merchant.
Keep the stack read running the whole time. Apps get installed and uninstalled, themes get updated, payment methods change, new carriers appear. A merchant who watches you notice a change they made three weeks ago concludes something about you that no amount of monthly reporting will ever achieve.