Why I'm building for Shopify first

I decided to build Hyp as a Shopify app first because of 'The Pixel'.

I've spent over twenty years in web analytics (from the days of Urchin.js!), mostly watching companies try and fail to get their data layer right. The amount of mind-numbing analytics audits I've run, figuring out why events are firing on the wrong page, or pageviews are firing twice, or event attributes are misnamed, is large.

And then there's 'The identity graph'. Either companies just completely ignore that most people use multiple devices, or pick a field (email) and assume it's consistent (it isn't).

Every new analytics platform or marketing platform purchase kicks off with a 3-6 month implementation (always following a needless 'kick-off call' where everything you've already told them is repeated back to you, or worse yet not even remembered). Someone is made responsible for implementing the tagging, and by the time it is done and working (and it's never working 100%) half the people who signed the contract have moved jobs and the project has lost its champion.

You can build the best agent or set of agents in the world and it doesn't matter if it's operating on bad data.

Shopify's pixel sidesteps almost all of this (as long as the store isn't in headless mode, something I'll design for later). It's already on the store. It tracks the most important e-commerce behaviours, such as product view, add-to-cart, checkout step, and purchase, all associated with the relevant user via a Shopify Client ID (cookie) and Shopify Customer ID (persistent ID for logged in users). The events are the same for every store, so I'm not writing custom mappers per customer. The merchant clicks "install", grants permissions, and within minutes we have a live datastream flowing in.

The shape of the events is also pretty reasonable. Any future e-commerce companies I onboard who aren't using Shopify should be able to copy them fairly easily. In addition to this I've designed the database that receives the raw events (BigQuery) to be event and event attribute shape agnostic. In other words, I'm not completely tied into how Shopify formats their events in case I need to pivot in the future.

Speed of onboarding is what I care about more than almost anything else right now. For a small startup trying to validate an idea, the faster I can show value to potential clients, without them having to do any work, the better.

Roughly 99% of Shopify stores are smaller e-commerce businesses, not the enterprise brands Hyp could eventually serve. If the long-term goal is selling six-figure contracts into procurement, Shopify-first doesn't get me there directly, and there's a real risk of anchoring the product to the wrong shape of buyer.

There's a second reason that lessens that risk, though.

A lot of Shopify stores are run by a founder, maybe a co-founder, sometimes a part-time freelancer doing the email. There is often no marketing team. There is no data analyst. The person looking at the dashboard is the same person who packed orders in the morning morning and answering customer support emails in the afternoon. They're not going to spend an hour figuring out what a cohort retention curve means. They want to know what to do next.

If Hyp can deliver useful answers to that person without them having to understand the data, without them needing to translate "lift in 30-day return rate" meaningful to their business, and it helps them make more money, then that is meaninful.

By comparison, large CRM teams at bigger brands are already somewhat comfortable with funnel analysis, have opinions about attribution models, and can translate a finding into a campaign brief (although I still believe they can do with help). They'll understand what I'm building faster because the vocabulary's already there. Plenty of tools work brilliantly when there's an analyst sitting next to them, and quietly fall apart when the operator is the same person doing fulfilment. I'd rather know now which side of that line we land on.

Bessemer's original investment memo on Shopify made the inverse case for the merchant side fifteen years ago: "The ability to offer cheap, consumer-like software opens a whole new market of customers (SMBs), who otherwise would find traditional enterprise software too complex and certainly too expensive." I think the same wedge that worked for the platform itself works for the tools built on top of it. SMBs let you iterate; enterprise is what you grow into once the iteration's done.

The thing I'm consciously hedging is the platform-dependency part of all this. I don't want to build a product that is so tightly tied to one platform that when the time comes to expand it needs a complete code re-write. So Hyp's core is only loosly tied to Shopify. The Shopify pixel is the first connector sending data into the system. (Although having said that, there are certain elements of the platform that ARE deeply integrated with Shopify, such as the on-site personalisation, which I also wanted to make as easy as possible for people to set up).

The risk runs the other way too. I could spend so long on the abstraction layer that the Shopify version takes too long to ship. So I'm keeping the abstraction thin but not too thin, proving the concept. The first two non-Shopify customer conversations will tell me whether I've dug myself into a hole.

For now I'm trying to keep the loop as small as possible. A Shopify merchant clicks "install." Within seconds Hyp is gathering their actual customer behaviour. By the end of the first day they're looking at decisions the agent has surfaced. Things they couldn't have seen by looking at their existing dashboards. By the end of the week, they know whether the tool earns its place in their stack.

A small Shopify store, a working pixel, and a customer who sees the value in a day. That's what I'm optimising for before anything else.