Three legs, one layer.

A fair question I get is why LayerKick does three things. Caching, insights, and server-side testing. The startup advice is to pick one, be the best in the world at it, and expand later. So doing three at once looks either ambitious or unfocused, depending on how generous you’re feeling.

I want to explain why it’s neither, because the reason is the whole thesis of the company.

They’re not three products, they’re one layer

Here’s the thing that took me a while to see clearly. Caching, insights, and testing look like three separate products because the market sells them as three separate products. There’s a caching vendor, an A/B testing app, an insights tool, and they each have a logo and a monthly bill.

But they all live in the exact same place: the layer between the shopper and Shopify. To cache a page you have to render it and serve it. To know what’s slow you have to watch it being served. To test a change you have to serve a different version. That’s one position in the stack doing three jobs, and the only reason they’re three companies is that nobody built the layer as a single thing.

Once you’re already the layer that renders and serves the page, insights are almost free, because you’re the one serving it and you can see everything. Testing is almost free, because you’re already deciding what to serve, so serving a variant is the same machinery pointed at a different page. The three legs hold up one table. Split them across three vendors and you pay three times for plumbing that should have been shared, and none of it talks to each other.

So the “focus” advice has it backwards for this particular case. The novel move isn’t picking one leg. It’s noticing that this layer exists, that it’s underexploited, and that the right unit of value is the whole layer, not a slice of it.

The pillar underneath all of it: complement, don’t encroach

There’s a second reason this works, and it’s the part I care most about getting right.

Shopify uses this same layer. It’s their platform, their edge, their checkout. LayerKick sits on top of it. The principle I hold to here is that we enhance Shopify rather than encroach on it. We’re a layer that makes their platform faster and more observable for the merchant, not a wedge trying to peel the merchant away from it.

That sounds like a values statement, but it’s actually a design constraint, and it shows up in real decisions.

The clearest example is Shopify Smart Pricing. When it launched, the lazy read would be that a platform-native pricing test competes with the testing we offer. It doesn’t, and we didn’t treat it like it did. If a merchant turns on Smart Pricing, LayerKick supports it. Their pricing test is what Shopify calls a treatment, and we make sure every visitor keeps seeing the correct treatment, served fast, right alongside whatever else the store is running. We work with it, not against it.

I hold every architectural decision to a simple test: if the people who build Shopify and the people who build Cloudflare looked at what we did, would they be glad we did it, or annoyed? If the answer is anything other than glad, the design is wrong, no matter how clever it is. A layer that fights the platform underneath it is a layer on borrowed time. A layer that makes the platform better for the same merchants is one both sides want to exist.

Why this is the whole company

Put the two together and you get the actual thesis. There’s a single layer between shopper and Shopify that nobody was treating as a unit, and it happens to be the exact place where speed, insight, and testing all live. The opportunity isn’t to build a better caching app or a better testing app. It’s to take that one layer and pack as much value into it as it can hold, in a way that makes Shopify and the merchant both better off.

Three legs, one layer, one platform we’re proud to sit on top of. That’s LayerKick, and it’s why the “just pick one” advice was never going to fit.