Introduction — Declaring the Platform Vision

Since 2022, Stailer has clearly communicated — both internally and externally — that we are evolving into a "platform." In June 2022, I laid out the definition of a platform against the contrast of aggregators and articulated Stailer's direction:

A platform focuses on providing tools that let third parties control the user experience, staying involved indirectly.

And in November 2022, I explored the specific demands placed on a platform serving large enterprise companies, and the direction that enterprise-grade platform should pursue.

2023 was a year of steady, sometimes fumbling, progress toward that destination. This post documents what we achieved in Stailer's platform journey this year, and where we stand now.

Publishing an Internal Platform Policy

We created and published an internal policy document for developing Stailer as a platform.

Two reasons drove this:

1. Escalating individual feature customization was creating a need for strong company-wide constraints
2. The entire business operation needed to evolve toward a model that could scale without relying on per-customer customization

As you can see, the policy takes a strong stance against individual customization. This has generated healthy debates internally: "Does this mean we need to eliminate existing custom features right now?" (A question I genuinely welcome.)

When setting a direction, I'd rather produce something that is clear about where we're going, even if there are costs, than something that's ambiguous. This approach seems to be working reasonably well.

Transitioning to Specialty-Based Development Teams

Over the past three years, Stailer has handled many "full system replacement" projects.

Full replacements are roughly 100x harder than launching a new net supermarket from scratch, because every single feature has active users. There will always be user stories that can't be dropped or handled without custom development.

For this reason, we had long organized teams around "assigning a development team to handle a specific partner's requirements." This was correct as a reverse-Conway application at the time.

But in April 2023, we made a major change.

We reorganized into specialty-based development teams, with partner concerns separated by domain rather than by partner. This was a reversal of the previous logic — and it represents a business paradigm shift: making the platform the center of the business and building the capacity to welcome diverse partners at scale.

What enabled this transition:

• A sufficient set of necessary Stailer features had accumulated, some of which were maturing
• We needed to shift toward teams that could own quality and operations sustainably
• We needed to lock domain expertise into fixed teams to reduce cognitive overhead

After the transition, intense debates arose around: where to draw ownership boundaries when splitting into multiple domains, how to handle source code ownership when the lines are blurry, and how to communicate requirements to development teams. We're working through all of it.

The transition has clearly delivered on "team specialization," "operational stability," and "long-term quality investment." We've grown more confident that this is the right direction.

Team transitions are always hard, but our Engineering Managers and Product Managers drove the project with care.

Quality Became a Stronger Focus

Stailer takes on partners' entire businesses, and we're betting on online grocery continuing to grow over the long term. That means very high quality is required. But for a long time, we didn't have the right resolution on what "quality" actually meant. This year brought major progress on two fronts.

SLOs

The first approach: articulate the most important user stories (Critical User Journeys) for Stailer users, define metrics (SLOs) based on them, and monitor and improve against those metrics. A special team was formed under direct CEO sponsorship, with PM Enami-san leading the effort.

We developed a clearer understanding of which uptime and response performance must be guaranteed for Stailer's core of cores, and were able to monitor status through objective metrics. Dashboard visualization was critical — our SRE team under babarot implemented it in Datadog in a matter of days and rolled it out company-wide. It was astonishing.

Defining Our Own Quality Framework

The second approach: based on our medium-term management policy announced in autumn, identify "product quality gaps" that need to be closed to achieve those goals. Concretely, we articulated the gap between current state and ideal state for the 8 quality characteristics in ISO/IEC 25010.

The conclusion: the biggest gap is in "maintainability." Digging deeper into maintainability, our own keywords emerged: "operational autonomy," "system operations efficiency," and "testability" (led by our CTO).

The quality management team's Broccoli-san gave me personal encouragement that capturing quality in your own vocabulary is itself the important first step. That validation meant a lot to me.

In H2 2023, we made this a top-priority company focus, with all teams visualizing, monitoring, and improving their operational autonomy and system operations efficiency.

Looking back, the definition I wrote last year — "platforms stay involved in user experience indirectly" — is exactly what operational autonomy means. A keyword that could only emerge from a company like Stailer, which takes on partners' entire businesses over the long term.

Quality is an endless journey. We haven't accomplished anything yet — but declaring "quality is our highest priority" and actually pursuing it company-wide is something I'm genuinely proud of.

FAST RETAILING's 2004 World Quality Declaration is my bible.

Internal and External Responsibility Lines Are Starting to Separate

In the earlier piece on Stailer as a platform, I imagined that eventually the platform would separate into a core and applications, with 10X owning the core and third-party developers owning the applications (similar to the Shopify App Store model).

Honestly, that vision is still alive — but because net supermarkets as a business haven't fully matured, I now view the path there as genuinely exploratory.

Meanwhile, work on separating core from application and clarifying which responsibilities belong inside Stailer vs. in external systems has begun. The clearest example is the "master data generation system" built through integration with partners' core systems.

This article describes how the product master — one of the most important data assets — is built, with source data received from partners:

We're in the process of clarifying the boundary between what Stailer is responsible for and what the partner's system is responsible for, in the data exchange between systems.

Previously, Stailer would absorb everything — fast to execute, but incurring excessive operational overhead as a result. Over the medium and long term, for both parties to run their businesses healthily, responsibility delineation is critically important. We're pushing forward on this.

In Summary

I've documented this year's progress toward "platformization" from my perspective, roughly 18 months after the 2022 declaration. My takeaway: platform transformation is not something a development team can drive alone — it only advances through a company-wide effort.

For example, improving "quality" requires revisiting source code and operations, adjusting expectations with partners, rethinking contract structures — essentially everything. It's not something that happens through one person's or one team's effort. It requires management to make the decision, set the vector, and accept the pain of moving in that direction.

Through all this work, I've become convinced: the key driver of Stailer's long-term, co-growth with partners is quality. And quality is the most important driver of Stailer becoming a real platform.

Work toward platformization is underway across every interface. I believe 10X will eventually satisfy the five points I laid out in the Enterprise Platform post. I'm sure of it.