Just Sake
An alcohol subscription platform built to lower the barrier to entry for sake newcomers through education and a zero-inventory logistics model.
The Problem
Building a subscription engine without the inventory risk.
The Market Gap
The Hong Kong sake market was mature but intimidating. Consumers were often expected to possess deep knowledge—distinguishing "Junmai Daiginjo" from "Honjozo"—and pay high prices per bottle just to experiment. The goal was to democratize sake culture by removing the "high price of entry" barrier.
The Unit Economics Problem
The business model carried significant risk: holding perishable, temperature-sensitive alcohol inventory is capital intensive. To make the unit economics work, the business required a Just-In-Time (JIT) supply chain—collect customer orders first, aggregate them, then execute purchase orders with suppliers only after cash was secured.
Platform Limitations
Standard e-commerce platforms (Shopify, WooCommerce) were built for "stock-first" logic and couldn't handle this specific aggregation-before-fulfillment workflow natively. The system couldn't rely on standard "stock deduction"—it needed to track "committed subscriptions" vs. "supplier orders" as separate concepts.
Constraints & Considerations
- Zero Inventory Logic — The system could not rely on standard "stock deduction." It needed to track "committed subscriptions" vs. "supplier orders" as separate entities, routing orders to suppliers only after payments were secured.
- Supplier MOQs — Suppliers impose Minimum Order Quantities (e.g., 12 bottles per case). The system needed to batch individual B2C subscriptions into valid B2B purchase orders.
- Solo Execution — As the sole developer and founder, the stack needed high "batteries-included" efficiency. I couldn't afford to reinvent auth or basic routing—Laravel's ecosystem was the pragmatic choice.
- Regulatory Compliance — Strict age verification (18+) and licensing data needed to be integrated into the checkout flow per Hong Kong regulations.
Approach & Execution
Rather than adapting a standard e-commerce platform, I built a custom system optimized for subscription economics and zero-inventory operations.
1. The "Reverse" Inventory Architecture
I chose Laravel for the backend API because of its robust Eloquent ORM, which was crucial for the complex data modeling required. Instead of a simple Order → Product relationship, I implemented a Subscription Aggregator: a cron job ran monthly to scan all active subscriptions (checking next_billing_date and status), then aggregated them into a "Demand List."
2. MOQ Optimization Algorithm
The algorithm grouped customer demands against supplier catalogs to optimize for MOQs. For example, if we needed 10 bottles but the MOQ was 12, the system flagged the variance for a decision: buy 2 extra for marketing use, or swap the SKU for one with better demand alignment. This allowed the business to operate with negative working capital—cash collected before stock purchased.
3. Custom Subscription Engine
Off-the-shelf subscription plugins failed at handling "Gifting" vs. "Personal" subscriptions in the same cart. I built a custom billing engine that separated Payer from Receiver. This allowed a user to buy a "3-month prepaid gift" for a friend (non-recurring) while maintaining their own "monthly recurring" subscription—all in a single database schema.
4. Decoupled Frontend (React + Redux)
The frontend was built as a Single Page Application to mask the complexity of the checkout logic. The checkout flow changed dynamically based on "Address Type" (Gift vs. Personal)—React state management handled validation instantly.
5. Educational "Hardware"
To solve the knowledge gap, the digital product was paired with physical assets. I designed and printed "Info Cards" included in every box, explaining the backstory, tasting notes, and brewery details for that month's selection. Education became part of the unboxing experience.
Outcome & Impact
Operational Automation
The custom Admin Dashboard became the ERP. It automated the generation of "Pick Lists" and "Supplier POs," allowing the business to run with negative working capital—cash collected before stock purchased.
Flexible Pivot
When B2C subscription growth slowed, the underlying architecture—built on flexible User and Role models—allowed a pivot to a Private Membership model without rewriting the core commerce logic.
Engineering Stability
The separation of the Laravel API from the React frontend meant the "business logic" remained stable and testable, even as we iterated rapidly on the UI to improve conversion rates.
Building for scale doesn't mean building big. Sometimes the right answer is a smaller, more engaged audience served with the same infrastructure. The technical foundation enabled the pivot without rebuilding.