I've been thinking about where e-commerce is headed, and after a run of conversations where this topic kept coming up, I want to capture my current thinking.
Net Supermarkets — A Special Kind of E-Commerce
Net supermarkets are a form of e-commerce, but they have quite distinct characteristics.
Take the concept of delivery slots and capacity. The UX required for buying 30 items in a single basket. The temperature-segregated fulfillment operations after an order is placed.
These differences might sound simple when listed out. But at the level of system design, the gap from other forms of e-commerce is enormous.
An EC that processes a single item into checkout and an EC that sorts 30 items by temperature zone and delivers them in a two-hour window are fundamentally different things.
That's why a dedicated core platform is necessary. This is the reason our Stailer business exists.
Why Shopify Doesn't Structurally Fit Net Supermarkets
Shopify is an outstanding product and ecosystem — capable of enabling a remarkably wide range of e-commerce scenarios.
But when you try to run a net supermarket on it, the story changes.
Managing delivery slots, controlling capacity against headcount, temperature-zone operational coordination... the list goes on. These aren't differences that can be absorbed through extensions on a general-purpose platform. Even if you could make it work, the complexity you'd have to accept would be enormous.
That's why Shopify doesn't structurally fit net supermarkets.
"We Want to Integrate" — A Common Customer Request
Our Stailer net supermarket platform receives a constant stream of customer requests.
Among them: requests to integrate with standard EC, reservation EC, rental EC, and similar services. From the customer's strategic lens — "consolidating all customer touchpoints to increase convenience and LTV" — this seems like a reasonable ask. Except for one thing.
The Cost of Integrating Systems with Different Characteristics
When you integrate systems with different structural characteristics and the codebase grows large, complexity scales exponentially.
I wrote about technical debt before — but the interest on debt is cognitive load, and as cognitive load grows, development velocity slows exponentially.
System integration and scaling at scale is exactly the kind of action that creates this dynamic.
Development and maintenance costs spike, and ultimately no single service achieves real quality.
That's why we can't easily say yes.
AI Changes the Entry Point to Shopping
But lately there's another angle to consider: the future of e-commerce after AI becomes widespread.
Conversational LLMs are already becoming aggregators, replacing search behavior. Using a chat LLM to research something is not just a substitute for search — it's become a genuinely superior experience.
I think the same thing is going to happen to the entry point to shopping. The hurdles are higher — payments, sharing personal information, real-time inventory sync are all required. But the infrastructure for AI agents to operate external services via API is already taking shape, and the technical barriers are dropping fast.
AI-Optimized Purchasing
A future where an AI, instructed by the user, surveys multiple sites and executes the smartest possible purchase on their behalf.
Say you instruct it: "Get a case of water and ingredients for tomorrow's dinner." That AI won't necessarily choose to buy everything in the same place just because it's convenient. It will solve the optimization problem — fastest, cheapest, most convenient delivery window — and aggregate: water from site A, groceries from sites B and C.
In this future, the user interface and system integration become nearly irrelevant.
What the user sees is one chat window. Behind it, multiple services are being selected and combined optimally.
What Makes a "Good Service" in an AI-Aggregated World
When that future arrives, what does a good service look like?
I think it looks like this: doing good commerce, simply.
In e-commerce terms: a service that delivers good products, cheaply, quickly. Polishing the fundamentals of the trade.
And the system underpinning that service will be simple, designed so AI can easily access its information, and high-performing.
Well-structured APIs and CLIs. Low-latency backends. Value lives there.
And service units will be minimal and independent. Continuing to operate such a backend requires minimizing technical debt accumulation — that constraint naturally produces that structure.
Simpler complexity means developers can also maintain the system more easily.
AI-friendly is also developer-friendly.
The Value of Suppressing Complexity
Super-apps like PayPay take the approach of integrating every possible function into a single UI. Today, the UI itself functions as a lock-in device — keeping users within the ecosystem.
But as AI takes over the user-facing touchpoint, that UI lock-in effect weakens. What the user sees is an AI interface. Which services are actually being used behind the scenes is selected optimally by the AI.
The type of service that holds value in an AI-aggregated era is the opposite of a super-app: simple, independent, API-first backend services. Each individual service behind the scenes is expected to be small, fast, and accurate.
An era where value lives in backend solidity rather than flashy UIs — I think that's coming.
"The reason we can't say yes to integration" was a technical judgment about avoiding exponential complexity. But when you consider what a service should look like in the AI era, that same judgment may turn out to be the business strategy of "being chosen by AI."
When an AI agent selects services, the evaluation criteria will be: completeness of the API, response speed, and machine-readability of the information.
A system that suppresses complexity, does one thing correctly, and is AI-friendly. That's what Stailer should be — and I believe we're already pointing in that direction.
