Case 02 — ezone.ly

Storefront Themes at ezone.ly — Turning a Vague Asking into a Shipped Feature

The Problem

ezone.ly serves around 140,000 active users, who have processed roughly 7 million orders and 76 million LYD in revenue through the platform. Every one of those merchants got the same storefront. Whatever they sold, their store looked like every other store on the platform, and there was no way for them to change that. The task I was given was one sentence long: create themes for the storefronts. No spec, no wireframes, no definition of what a "theme" was supposed to mean, and no decision about whether merchants would pick from a list or design something themselves.

That gap was the actual problem. Building the wrong version of a theming feature would have cost weeks, and the ambiguity meant any version I built could be called wrong afterwards. Before writing code, I had to turn the sentence into a decision the team could stand behind.

My Approach

I started by looking at how the platforms merchants already compared us against handled this. I went through Shopify, Salla, and Zid, created test stores where I could, and took screenshots of every step of their theming flow: what a merchant could change, where the settings lived, how the storefront reflected the change, and whether anything was paid.

Two patterns came out of it. All three let merchants change colors and brand identity: logo, palette, fonts. That was the baseline; shipping less than that would have looked like a gap. Beyond the baseline, the stronger platforms ran a theme store, where the storefront layout itself was swappable and premium themes were sold for money.

I put both options into a presentation with wireframes and booked a meeting with my direct manager rather than sending it over chat. Option one was the baseline: a settings panel for colors and brand identity, applied to the existing storefront. Option two was a theming engine: storefronts rendered from a theme definition, so new layouts could be added without touching the core, and a store could be built on top of it. Option two was my recommendation, and the argument was revenue. Paid premium themes would turn a feature every competitor gave away into a product line.

I also put the cost next to it. The engine was a multi-month build touching the storefront rendering layer, and other features were already waiting on the same team. I walked into the meeting expecting option one to win. I presented option two anyway, because the decision belonged to the stakeholders, and they could only make it if someone showed them the full decision space. My job was to make the choice informed, not to make it for them.

We agreed on option one. That was the right call for the quarter, and I said so in the meeting.

Challenges

The hardest part was defining scope for a feature that had none. Once we chose the simpler option, "colors and brand identity" still had to become a list of exactly which properties a merchant could change and how each one propagated through the storefront. The list we settled on had three parts: colors, which sections appeared on the storefront and in what orientation, and a small set of settings per section. Free-form layout editing stayed off the list; that was the engine, and we had already decided not to build it.

The second challenge was doing this without breaking existing stores. Every live storefront had to keep rendering identically until its owner chose to change something. We handled that with default values for every theme property, stored in the backend and matching the current look exactly, so a store that never opened the new feature never changed. The backend developer owned the defaults; my side was making sure the storefront rendered from them identically before any merchant touched a setting.

What Was Shipped

Merchants found a new button in their dashboard, marked with a "new feature" tag. Opening it showed the theme settings alongside a live preview of their storefront, so every change to a color, a section, or a setting was visible before it went live. A store could go from the platform default to its own identity in one sitting, without a designer and without support tickets. More than 100 stores changed their theme in the first month. The feature matched what we had agreed in the meeting, with nothing added and nothing cut.

The engine proposal and the competitor analysis stayed documented as the next step. It was never picked up; other work kept taking priority. I do not count that as a loss. The team made the decision with the full picture in front of them, and the feature that shipped was the one they had chosen.

What I'd Do Differently

I would keep the process: research the market, present the options with their costs, recommend, and accept the decision. It produced the right scope and it produced it before any code was written.

What I would do better is the pitch for the engine. The revenue argument was a direction, not a number. I had screenshots of competitors selling premium themes but no estimate of what a theme store could earn on ezone.ly: how many of our merchants would pay, at what price, against what build cost. Stakeholders were comparing a concrete cost on one side with a vague upside on the other, and a vague upside loses that comparison every time. A stronger presentation would have gathered that data first, from competitor pricing and from our own merchant base, and put a figure on the table. The answer might still have been no. It would have been a no to a real proposal instead of to a promising idea.