Scaling Coda’s Webstores — From Bespoke Builds to Publisher Self-Service

From portal to D2C platform

When I joined Coda in 2023, Publisher Portal was mostly an internal tool for settlement reporting.

Over the next two years, it evolved alongside the business: we streamlined the publisher journey, launched our first highly customized D2C webstores in 2024, and validated the model with flagship stores generating multi-million-dollar revenue. By the end of 2024, a basic internal store builder had reduced initial store creation to roughly two days.

The next challenge: making it scalable

We had validated the business and accelerated internal store creation. The next challenge was scaling without treating every new store as another bespoke project.

Earlier, we had accepted these limitations while validating the business.

Customization helped us prove the model. It also made scaling harder.

Our early webstores followed two approaches. Custom commerce supported games such as CODM and FCM through highly tailored storefronts, while instant commerce offered a more standardized experience on separate infrastructure.

This helped us meet different publisher needs, but left us with stores built in different ways. Many interface elements weren’t reusable, and some stores even used different framework versions, including Vue 2 and Vue 3.

A routine campaign update—highlighting a product, applying a seasonal theme, or changing a product-card layout—could require separate implementation work across stores.

The strategic shift: supporting different stores at scale

Our initial focus was making each publisher’s store work for their specific needs. As the platform grew, the question expanded: how could we continue supporting that variety without each new store adding the same implementation and maintenance effort?

Customization remained important. What changed was how we intended to support it: a shared Commerce Engine underneath different storefront experiences.

The flexibility publishers valued was difficult to scale with the way our stores had evolved.

Commerce Engine gave us a shared foundation. The next challenge was making store creation usable by publishers without the operational knowledge Coda’s teams relied on.

A working storefront came too late in the flow

Our first instinct was to improve the existing sequence: create a title, add products, configure the store, then preview the result.

But this meant publishers had to complete the setup before seeing their own storefront. We began questioning which steps were necessary upfront and which could happen after publishers had something tangible to work with.

What changed our thinking

To explore which steps could move later, we reviewed the existing flow, observed how Ops handled setup, and examined how other products introduced users to their first result.

These observations led us to explore a different sequence: show publishers an initial storefront, then guide them through the remaining configuration.

Design concepts

I developed three contrasting directions to examine where publishers should first experience value, how much setup they should complete upfront, and how store creation would connect to ongoing management. Each direction represented a hypothesis to investigate.

Early evaluation with BD and Ops

Direct access to publishers took longer than our timeline allowed. To get early feedback, we asked Business Development (BD) and Operations (Ops) colleagues to walk through the concepts as if they were creating a storefront for their company.

What we wanted to understand

• Was the next step clear, and where did they need an explanation?
• Did they understand what the system generated and what remained to be completed?
• At what point did the storefront feel useful enough to continue?
• How did they expect creation to connect with their account and ongoing store management?

How we interpreted the feedback

Participants already understood Coda’s terminology and processes, so their familiarity could hide difficulties a publisher might encounter. Taking on a publisher’s task did not remove that limitation.

We also considered patterns from previous publisher interactions. These provided context for interpreting the feedback, while the internal walkthroughs helped us identify potential issues in the proposed experience.

We used these inputs to refine the concepts and form working hypotheses for later publisher validation.

What this suggested—and what remained untested

• Showing an initial storefront earlier might help publishers understand the value before completing setup.
• Automating repetitive setup might reduce upfront effort, provided publishers could review and correct the generated content.
• Keeping creation inside Publisher Portal might make the transition to account and store management clearer.

We still needed to test whether publishers unfamiliar with Coda could complete the flow independently, understand the generated result, and move confidently into the remaining setup.

Why we chose creation inside the Portal

We chose Option 3: AI-assisted creation inside Publisher Portal. The Portal was already where publishers would manage their stores, so keeping creation there connected the generated storefront to its ongoing setup and management. This also avoided introducing a separate website-to-Portal handoff.

The tradeoff was that publishers needed to enter the Portal before seeing a generated store. We accepted that constraint for the initial release, while leaving generation before Portal onboarding as a direction to explore.

The direction we shipped

The shipped Store Builder used a publisher-provided Google Play, App Store, or Steam listing URL to generate initial store content, reducing the amount they needed to configure from scratch.

Initial store creation

Compared internally with the required inputs ready; excludes KYC, approvals, and other launch requirements.

WYSIWYG wasn’t the wrong idea. The sequencing was.

Bespoke work can be the right starting point

Custom implementations helped us meet publisher needs while validating D2C. Looking back, I wouldn’t treat that early approach as a mistake. The lesson was recognizing when a useful compromise had become a constraint—and when shared capabilities deserved greater investment.

Faster creation is only part of self-service

We focused on getting publishers to an initial storefront quickly, but visual customization remained limited. This taught me to distinguish reaching the first result from having enough control to make that result useful. It shaped how I approached the next phase of the visual builder and design system.

Internal familiarity can hide complexity

Working with BD and Ops helped us evaluate concepts when publisher access was limited. But their knowledge of Coda could also make unfamiliar steps appear straightforward. I learned to separate what those sessions could reveal from assumptions that still needed direct publisher testing.

In 2026, the visual store builder and supporting design system entered soft launch, extending the work toward greater publisher control over storefront appearance.