Commerce Built for Customers: Why What You Measure Determines What You Build

There is a question that gets asked far too rarely at the start of a commerce implementation: who are we actually building this for? The obvious answer is the retailer, the brand, the client sitting in the room. But the honest answer — the one that determines whether a commerce platform succeeds or fails — is the shopper.

And the shopper is almost never in the room.

The Brief Is Not the Product

Every commerce implementation starts with a brief. Features required, integrations needed, platform chosen, timeline set. That brief reflects what the client needs to run their business. It is necessary, and it is right to deliver it well.

But the brief is not the product. The product is the experience a shopper has from the moment they land on the site to the moment they complete a purchase — and every moment after that. Those two things are not always aligned. In fact, in our experience, they frequently are not.

We have seen commerce platforms built to an exact specification that were genuinely painful to use. Every integration was in place. Every payment method was configured. Every report worked. And the conversion rate told a different story entirely. Because the specification was written by people thinking about the business, not the person buying from it.

The South African Commerce Reality

This gap between brief and shopper experience is particularly consequential in the South African market, where the end customer reality is more demanding than most commerce builds account for.

South African shoppers are predominantly mobile-first. They are often operating on constrained data packages. Payment trust is earned, not assumed — a poorly positioned payment flow or an unfamiliar gateway creates friction that costs conversions. Delivery expectations have been shaped by an uneven logistics infrastructure, which means how you present shipping options and manage expectations is part of the product.

When we build commerce for South African clients, we are building for a shopper who is likely on a mobile device, possibly on a prepaid connection, comparing two tabs before deciding whether to trust this checkout. The implementation choices that serve that person are not always the same choices that serve the brief.

Designing from the Cart Backwards

The methodology we have developed — and the one we push back to clients who have not considered it — is to design from the cart backwards. Start with the checkout. Start with the payment moment. Start with the point of maximum intent, where the shopper has already decided they want to buy and is one bad experience away from leaving.

Once you have designed that well, work backwards through the product detail page, the search and browse experience, the navigation, and the homepage. Every layer should be optimised to get the right shopper to that checkout moment as efficiently as possible — and to make sure they complete it when they get there.

This sounds obvious. It is not common practice. Most commerce implementations are designed from the homepage forward, which reflects the client’s mental model of their business rather than the shopper’s journey through it.

Measuring What Actually Matters

Feature delivery is not a measure of commerce success. It is a measure of implementation completion. They are different things, and conflating them is how organisations end up investing significantly in platforms that underperform.

The metrics that tell you whether a commerce platform is working for its end customers are conversion rate by device, checkout abandonment by step, basket size over time, and repeat purchase rate. These numbers are available from day one post-launch. They tell you what the brief cannot: whether the people using the platform are actually finding value in it.

We make it a practice to define these metrics before implementation begins — not as a post-launch report, but as part of the design criteria. When a team knows they will be measured on checkout completion rate, not just checkout feature delivery, they make different decisions at every stage of the build.

The Question That Changes Everything

There is a single question that we return to throughout every commerce engagement, at every stage of the build. It is simple, it is not always comfortable, and it is consistently underused.

Would I use this?

Not as the client. Not as the developer. As the shopper. Would I complete this checkout on a mobile device? Would I trust this payment page? Would I understand what is in my basket and what it is going to cost me? Would I know when my order is arriving?

When the answer is yes — genuinely, not aspirationally — the platform is ready. When the answer is “probably, with some explanation,” it is not. That question, asked honestly at every review point, catches more conversion-killing problems than any specification review ever will.

What This Looks Like in Practice

In practice, building for the end customer means a few things that clients do not always expect from a commerce partner.

It means challenging feature requests that create friction for shoppers, even when those features make operational sense. It means insisting on mobile-first design review at every sprint, not just at UAT. It means setting up real device testing against the South African network conditions the shoppers will actually experience. It means mapping the shopper journey before wireframing the platform, so the UX reflects how people actually move through a purchase rather than how an org chart assumes they will.

It also means having honest conversations about what has been built when post-launch data reveals a problem. Commerce is not a one-time delivery. The platform should get better for its end customers over time — and the data to drive that improvement should be embedded from the start.