TechCut — Technical Case Study · OneSiam Super App Project
Most e-commerce systems are designed around a fairly straightforward problem.
Customer selects products → System creates an order → Store or warehouse prepares the items → Delivery goes out
But when the problem shifts from “one online store” to “a shopping destination with multiple brands, multiple systems, and multiple ways of serving customers” — the complexity scales immediately.
Imagine a single order containing items from multiple stores inside the same mall.
- Each item might come from a different brand
- Each store manages its own stock, its own operations team
- Its own promotional conditions, and potentially its own backend systems
But from the customer’s perspective, what should happen is simple: select products, pay once, and receive a continuous experience that feels like one order.
This is the technical challenge behind OneSiam Super App.
The Hard Part Isn’t Building the Storefront
At face value, OneSiam Super App might look like an e-commerce platform where customers can browse products, use member benefits, and access various services.
But the real complexity sits behind the scenes.
Because the system doesn’t just need to handle products and carts. It needs to support an ecosystem where multiple parties operate together: customers using the app, brands and stores across the mall, operations teams working on the ground, the membership and benefits system, the payment system, the parking system, external partner systems, and the organisation’s existing legacy backends.
So the challenge of OneSiam Super App wasn’t simply building an e-commerce platform. It was building a Commerce Orchestration Platform — one that makes multiple systems, multiple stores, and multiple journeys work together as one.
Multi-Tenant Commerce: When Every Store Is Its Own Sub-System
One of the core architectural concepts in this system is Multi-Tenant Commerce.
In a typical e-commerce setup, one store often owns a single system, a single warehouse, and a single workflow. But in a shopping mall, each store operates independently — with its own inventory, pricing, promotions, product management approach, and business conditions.
So the system had to support multiple stores within a single platform while allowing each store to maintain its own logic.
What the system needed to manage:
- Separate products and orders by store
- Maintain independent status tracking per store
- Handle product data, pricing, and stock per tenant
- Support different discount and promotion conditions across stores
- Unify all of this back into a single customer journey
This is the difference between building an Online Store and building a Marketplace or Ecosystem Platform.
An online store sees products as items for sale — an ecosystem platform has to see each store as a Tenant with its own business logic.
Order Splitting: Complexity the Customer Should Never See
One of the core pieces of logic in this system is Order Splitting.
From the customer’s side, buying from multiple stores should feel like placing a single order. But from the system’s perspective, that order may need to be broken into multiple parts — so each store can manage their portion correctly.
When an order contains items from multiple stores, the system needs to:
- Split the order by the relevant store
- Route information to the right store or operations team
- Track each portion’s status separately
- Consolidate status into something the customer can easily understand
- Handle cases where certain items are cancelled, modified, or refunded — without disrupting the whole order
A good platform hides this operational complexity behind the scenes — and presents the simplest possible experience in front.
Fulfillment in a Mall Is Not Fulfillment in a Warehouse
Another key difference is Fulfillment.
Most e-commerce systems are designed with a warehouse at the centre. But in a shopping mall, inventory is distributed across individual stores in a physical space.
That means fulfilment doesn’t always happen from a warehouse with clear shelf locations. It happens in the real physical environment of the mall.
The system needed to support a more complex workflow: receive orders from multiple stores, generate pick lists for each location, track preparation status per item, handle cases where certain items aren’t ready, consolidate items before handoff or delivery, and keep the customer updated throughout.
This is the point where Technical Architecture has to understand real-world Operations.
Because if you design the system purely from an e-commerce software perspective, you might produce a flow that looks correct on screen — but is difficult for the team actually walking the floor to use.
Integration Layer: What Makes a Super App Actually Work
A Super App doesn’t derive its value from a large number of features alone. The real value emerges when those features connect with the organisation’s real systems and its partners.
In OneSiam Super App, the platform needed to integrate with: membership and benefits systems, payment systems, loyalty points systems, in-mall services, store and product data systems, and external partner systems.
The challenge of integration isn’t only about whether an API call succeeds or fails.
It’s about making systems that have different data formats, different sync speeds, and different limitations work together — without disrupting the user experience.
- Some systems may be real-time
- Some may run on batch processes
- Some have data constraints
- Some carry their own specific business rules
So the Integration Layer has to do more than act as a “connector.” It has to translate data, handle errors, manage flow, and allow many different systems to compose into a single experience.
Financial Logic: The Part Users Never See, But Can’t Get Wrong
In a system with multiple stores and multiple business conditions, the financial layer is another area of significant complexity.
When a customer makes a single payment, the backend may need to calculate several things simultaneously: revenue per store, discounts from multiple sources, applied member benefits or points, refunds on individual items, partial order cancellations, and data required for subsequent reconciliation.
The difficulty of financial logic isn’t just the calculation itself.
It’s making sure every party within the ecosystem sees consistent, accurate, and auditable data.
This is something customers may never see — but it is the foundation of the platform’s trustworthiness.
Engagement Features: Small Features That Make the App More Than a Checkout
A good commerce platform shouldn’t only activate when a customer needs to buy something. Because if an app is only used during transactions, the likelihood of return depends entirely on whether the customer happens to want to buy something at that moment.
OneSiam Super App therefore included features that extend the role of the app beyond purchasing:
- Saving products of interest
- Notifications when relevant products or benefits become available
- Content connected to the customer’s lifestyle
- Exclusive privileges and campaigns that create reasons to return
These features may seem small compared to the core commerce system. But in product terms, they help transform the app from a Transaction Tool into an Engagement Platform — and this is where technology begins to connect with real user behaviour.
Infrastructure Designed for Uneven Load
Commerce platforms don’t have uniform traffic every day. At certain times, usage spikes — from campaigns, promotions, events, or seasonal peaks.
So the system needs to handle uneven load without over-provisioning at all times.
Key principles for this type of system: support scaling when traffic rises, deploy safely with auditability, have rollback processes when issues arise, load test before going live, and meet security and data privacy standards appropriate for the organisation.
These aren’t features users see. But they’re the foundation that allows the platform to actually operate at enterprise scale.
Build Doesn’t Mean Done: Platforms Need a Lifecycle
A digital platform with a complex ecosystem isn’t something you build and finish.
After going live, the system still needs ongoing care, improvement, and extension. Because once a platform is in use, new things always emerge: operational issues not visible during design, new requests from the business team, new campaigns that need configuration, new integrations that need to be added, performance or usability adjustments, and insights from real user behaviour.
This is why platform work shouldn’t be treated as a one-time delivery project — it should be treated as a product that needs to grow.
For Muze, the role of a Tech Partner isn’t just to build a system and hand it over. It’s to help the organisation maintain, improve, and extend the platform to meet real business needs over the long term.
5 Technical Lessons from OneSiam Super App
1. E-commerce for an ecosystem requires Orchestration thinking, not just Transaction thinking
When a system has multiple stores, multiple partners, multiple benefits, and multiple workflows — thinking purely in transactions isn’t enough. A platform needs to be able to orchestrate multiple systems working together. This is the difference between “receiving an order” and “managing an entire order journey.”
2. Good complexity is complexity the user never has to see
The backend may be highly complex — order splitting, fulfillment, integration, reconciliation, exception handling. But from the user’s perspective, the experience should be as simple as possible. The platform’s job is to hide the complexity behind the scenes and deliver a fluid experience in front.
3. Physical operations must be designed into the system from the start
If a platform needs to connect with a real physical space — a mall, stores, or an offline operations team — the system can’t be designed from the screen alone. A digital platform that connects with the physical world needs to design both the software flow and the operations flow together.
4. The Integration Layer is the heart of an enterprise platform
In a large organisation, new systems almost never start from scratch. They almost always need to connect with existing systems, existing partners, and existing workflows that already have their own constraints. So a platform’s capability isn’t measured only by the new features it builds — it’s also measured by its ability to integrate with the ecosystem that already exists.
5. Technical architecture must support the growth of the business model
Super Apps and Ecosystem Platforms rarely stop at the first features they launch. So good architecture isn’t just about meeting today’s requirements. It has to open the path for the business to extend and grow in the future.
In Summary: OneSiam Super App Isn’t Just E-commerce — It’s an Enterprise Commerce Platform
Behind OneSiam Super App sits a technical challenge more complex than building a typical online store. Because the system needs to support: multi-tenant commerce, order splitting, physical fulfillment, loyalty and member privileges, integration with existing systems and partners, financial logic, engagement features, enterprise-grade infrastructure and security, and ongoing maintenance and extension post-launch.
The challenge of this project wasn’t just helping customers tap to buy products. It was making the complex ecosystem of a luxury shopping destination work together on a single digital platform.
For organisations building their own platform, the key lesson is:
Don’t think of a Digital Platform as just a new screen for your business. Think of it as a central system that connects Business Logic, Operations, Data, Integration, and Customer Experience together.
Because a good platform doesn’t just help a business “go online.” It helps the business expand its own ecosystem — and actually grow.