"How do you handle customization requests from multiple customers?"
This is a question I get constantly — from hiring interviews, from potential partners, from recruiting candidates, from investors. I want to write down my current answer as it applies to Stailer.
Three perspectives behind the question
Stailer's business model is partnership-based: we support retailers in launching their online grocery businesses using the Stailer platform. The inevitable question is "how much customization will you do?"
When thinking through this, I consider it from three angles.
Product developer perspective: Accepting customization requests and implementing them as asked ultimately means letting the customer's demands drive the product. At 10X, we hold a strong conviction that you cannot create significant value by building a product this way.
Executive / shareholder perspective: Typical customization is hard to reuse. It degrades resource efficiency across the board. Revenue might increase short-term, but it compresses gross margin. It's a deterioration of the business's performance.
Partner perspective: Partners naturally want their development requests accepted — they need the product to advance their business, and they're concerned about whether they have enough freedom to do that.
Our answer to all three of these perspectives is the same: abstraction.
Abstraction vs. fragmentation
At 10X, we believe: the more impactful something is, the more it should be abstracted. The opposite of abstraction is what we call "fragmentation" (we use this term loosely).
What does an abstracted product look like? Consider two different requests from two different partners:
- Company A: "Let users buy products from within a recipe"
- Company B: "Let users see recipes for products they're looking at"
Hard-coding a specific solution for each request is fragmentation. In contrast, clarifying what Company A and Company B (and potentially all future partners) are trying to accomplish — and building a solution that addresses the underlying issue at a general level — is abstraction. That's Stailer's approach.
In this example: build a metadata database connecting products (carrots, onions, etc.) to the recipes that use them. With an API that exposes this data cleanly, "load recipes from a product" and "load products from a recipe" are both solved. And with this abstract foundation in place, you can agilely test "which UI actually delivers the most value to users" for both use cases. When we determine a feature is something every net supermarket needs, we abstract it and add it to Stailer — available to all partners.
What does fragmentation look like? Say Partner A asks: "Put today's discounted sake at the very top of the page." Implementing this specific request by hard-coding it into the frontend is technically trivial. But Stailer essentially never does this.
Why not? Because that hard-coded solution can't be reused when other partners have a similar need. That's fragmentation. The better solution: build abstract control — "let operators control the display order of specific products" — and the whole product becomes more productive.
That said, when the impact is unclear, we sometimes allow "short-term fragmentation" where we throw away the implementation cost. But no matter how diverse our partners become, the business is fundamentally the same: retail and distribution EC. The underlying needs from partners and end users are similar in nature. When we receive one request, we always expand our thinking to N partners and evaluate whether abstraction is appropriate.
Fattening Stailer's value
One of our company values is "work back from 10x." 10x value is non-linear value delivered by solving someone's deep problem. The right stance isn't to absorb what someone asks for — it's to break down the structure and cause behind the request, define it as a strong issue, and build the best tool to address that issue.
When you do this, you don't just satisfy the one partner who made the request. You satisfy other partners with similar needs. And you attract new-to-market players who couldn't launch online grocery before. That's business value added.
What we're doing isn't customization — it's fattening Stailer. By fully engaging with each N=1 request from partners and end users, we maximize the potential of the Stailer product. And for partners who don't need a particular capability, we make it easy to simply switch it off.
Admittedly, net supermarkets and Stailer itself are still young, so there are many foundational capabilities still missing. Right now, digging into the issues behind various requests usually results in absorbing most of them into Stailer. That will shift as the product matures.
To directly answer the original question: "We don't do customization. We redefine specific requests as universal issues, abstract the value as much as possible, and build it into Stailer. We make that value available optionally. We don't build fragments. Everything we build becomes an asset that can serve multiple partners — which means a stronger gross margin impact across the board."
Abstraction also applies to operations
So far I've been talking about product. But 10X creates value not only through product — we also support partners operationally: helping launch new operations, making existing operations more efficient, providing consulting, and in some cases running BPO (business process outsourcing) operations directly.
Net supermarkets have three "heartbeat" operations:
- Inventory management
- Pick and pack
- Delivery management
For pick-and-pack, for example, we go on-site, set up the operation, provide the supporting product, and support the launch. We absorb learnings from each site and continually increase the depth of our operational knowledge — and then abstract that knowledge into reusable patterns.
A 10X team member going into a new facility should be able to assess it quickly and say: "For this site, the pick-and-pack operation should use Method X. The appropriate system configuration is Pattern A of the five options."
Two patterns of operations DX
After supporting a range of partners, I've noticed two distinct types of operations DX:
- Leverage on operations that are bottlenecking revenue — for net supermarkets, inventory management and pick-and-pack are exactly this
- Simple cost reduction
These are fundamentally different. The first is a revenue driver for the partner. For 10X, with our revenue-share model, improving these operations increases partner revenue — which directly increases our gross margin. Perfect alignment for all parties.
The operations that can't be (and shouldn't be) abstracted
Finally: BizDev — which I deliberately don't abstract.
BizDev has two components: relationship and success.
Relationship means building trust, assembling deals, doing lead generation, negotiating on equal footing, and ultimately producing an agreement (contract). Stailer is a product that only founders and executives can buy, because it's about business transformation. This means relationship work has to be done alongside the founder or president of the partner company. And closing contracts requires careful negotiation to find mutual terms, point by point.
Success means judging the Fit & Gap between the partner's pain (and the end user behind them) and the value we can deliver — and then actually delivering the fit value to make the partner succeed and convert it into gross margin.
Success can be somewhat abstracted. Relationship cannot. Every company has a unique, detailed context and strategy that must be understood individually:
"What's their geography, what was their original business, what's their current position, what's the environment around them?"
Each company's story is surprisingly unique. We research our partners more deeply than they research themselves, understand their situation fully, and only then propose the best path.
We very often advise partners: "Stailer isn't right for you right now" or "now isn't the time." That's the situation where the interests of the partner, their users behind them, and 10X don't align. When any one of those three has a distortion, we judge that building a long-term relationship is difficult.
In typical sales, turning away a deal is a negative. For us, it's the opposite. We want partners to be genuinely ready to succeed with net supermarkets. Forcing Stailer onto a partner who isn't ready doesn't serve anyone.
Two things make this decision possible: (1) 10X has sufficient resource management that we can be selective; and (2) we've chosen a business model aligned with partner growth. Both enable us to go all-in on partners who are truly ready.
Building a relationship of mutual respect with the retailers who have sustained Japan — and being able to drive real innovation together — is direct, interesting, pressurized, and exciting.
