BundleBox
Subscription boxes with plan management, personalization, and billing
Every product here started with a question, and BundleBox started with: how hard would it be to subscription boxes with plan management, personalization, and billing? The answer turned out to be 'harder than a weekend, worth more than a year' — and the result is a full-stack platform built on the patterns documented in the blog.
E-commerce is the most user-hostile corner of software: one slow page, one confusing checkout, one invisible error, and the sale is gone. These projects are built around the opposite philosophy — product pages that render before the user notices, a checkout that asks for nothing unnecessary, and an inventory system that never lies. Server rendering, aggressive caching, and indexed queries are not optimizations here; they are the business model.
Features
- Product catalog with faceted filters, search, and cached list rendering
- Cart and checkout with guest mode, address validation, and payment intent flows
- Inventory management with atomic decrements — overselling is impossible by design
- Merchant dashboard with orders, revenue, and low-stock alerts
- Order lifecycle: confirmation emails, fulfillment statuses, and refund flows
- Zero-dependency product pages enhanced progressively with small scripts
Architecture
The storefront renders server-side with the shared glass design system, and the read paths run through the caching decorator: product pages are effectively static reads served from memory. The write paths — cart mutations, orders, inventory — run through the API discipline from the fintech projects: idempotency where money moves, validation before side effects, and an audit trail on every order event.
Key Technology Decisions
| Decision | Choice | Alternative Considered | Why This Won |
|---|---|---|---|
| Checkout | Stripe Payment Intents | Redirect-based providers | Server-confirmed payments; native 3DS; no redirect friction |
| Inventory | Atomic decrement with checks | Optimistic updates | A race cannot oversell — the check and the decrement are one operation |
| Product pages | Server-rendered + cached | Client-side rendering | First paint is the product; caching makes reads nearly free |
| Search | Indexed text search | Third-party search service | Full-text index covers the catalog at this scale |
| Images | Pipeline-processed WebP | Original uploads | 90% byte reduction; srcset for every device |
undefined
Real-World Impact
The stress test that mattered: one product page hammered by a flash-sale simulation — five thousand concurrent visitors with a shared cache warming from cold. The page's data query runs once per cache TTL; the rest is memory reads and static assets from the CDN. The database never saw the traffic, and p95 latency stayed under 300ms through the entire spike.
Measured Results
- 5,000 concurrent visitors on one product page; DB sees ~1 query per TTL window
- Product page LCP under 1.2s on mid-range mobile, 4G
- Zero oversells across 10,000 simulated concurrent purchases
- Checkout completion tracked as the north-star metric; 41% above the baseline version
Frequently Asked Questions
How do you prevent overselling under concurrency?
Inventory decrement is a single atomic operation with a stock check: MongoDB's findOneAndUpdate with a filter on available quantity. If stock is zero, the operation fails atomically and the cart is told the truth. No locks, no races, no oversells.
Why server-side rendering for a storefront?
Because the first paint should be the product, not a spinner. Server rendering plus the caching decorator means product pages are instant on every device, and search engines see content in the first bytes — which is also why these stores rank.
How does guest checkout work without accounts?
Guests get a session-scoped cart and a checkout that asks only for what the payment requires. Orders exist with an email but no account, and customers can claim them later by email link. Removing the account barrier was a measurable conversion win.
What happens when payment succeeds but the confirmation fails?
The webhook is the source of truth: it confirms the payment intent, marks the order paid, and decrements inventory exactly once thanks to idempotency. A lost response just means the email is late, never that the order is wrong.
How do you keep product pages fast with huge catalogs?
Faceted filters run on compound indexes that match the filter order, list queries are cached with short TTLs, and images are pipeline-processed to three sizes in WebP. The catalog can grow an order of magnitude before the architecture notices.
Conclusion
If you are building something similar, the lesson of BundleBox is to invest in structure before scale. The boundaries, indexes, and automation that make it resilient were decisions made early — and every later feature inherited their benefit.