Building The Snack Gospel: A Marketplace Sandbox
The Snack Gospel is an international snack marketplace with a retro-chic personality — the kind of store where browsing is half the fun. It started as an embedded prototype inside this portfolio site and now lives on its own domain as a standalone product.
This is a candid write-up: what it is, how it's built, what was hard, and what's honestly still unfinished.
The problem (and the excuse)
If you've ever wandered the aisles of an H-mart, you know the feeling: shelves of snacks you can't read the labels of, any of which might be your new favorite thing. Online, that discovery experience mostly doesn't exist — snack e-commerce is either a search box or an infinite grid.
The Snack Gospel is my sandbox for a specific product question: can you design browsing that feels like wandering, not querying? It's also, candidly, an excuse to build a complete e-commerce stack end to end — catalog modeling, cart state, checkout, and webhooks — without a client deadline attached.
The product concept
Three browsing modes, all built around discovery rather than search:
- By region — classic category navigation (East Asia, Southeast Asia, and so on).
- By vibe — taste-first tags like sweet, spicy, crunchy, or chewy, because "I want something crunchy" is how snack cravings actually work.
- By map — an interactive world map where countries light up if they have products, and clicking one filters the shop to its snacks.
The catalog is currently 20 real products, each modeled with a region category, a taste-vibe tag, and a country of origin — enough dimensionality to make all three browsing modes genuinely different paths through the same inventory.
Architecture and decisions
The stack is deliberately boring: Next.js App Router, TypeScript, Tailwind, and Stripe Checkout, deployed on Vercel. A few decisions worth noting:
- A flat, typed catalog instead of a database. Twenty products don't need Postgres. Products live in typed TypeScript data with helper functions for filtering by region, vibe, or country. The interesting part is the shape of the data, not the storage.
- Stripe as a boundary, not a dependency. The checkout API checks for Stripe configuration at request time. Without a secret key,
GET /api/checkoutreports{available: false}, the checkout page renders a polished "payments disabled" state, and nothing errors. The site is fully browsable as a demo and flips to real payments by setting two environment variables. - The map loads its geography at runtime from TopoJSON rather than bundling it — a tradeoff between bundle size and a runtime dependency that I may revisit.
What was hard
The honest challenges were less about code and more about product surface area. E-commerce has a long tail of states: empty carts, empty categories, products without images, checkout with payments disabled, webhook verification. Every one of those needed a deliberate decision, and the "demo mode" path needed to feel intentional rather than broken.
The other lesson: extracting an embedded prototype is real work. The original version lived inside my portfolio under a path prefix, with a password gate and portfolio-specific assumptions threaded through it. Making it standalone meant reconciling two divergent implementations and untangling every path assumption — a small preview of what production migrations feel like.
Current status
Live at thesnackgospel.com. Browsing, cart, vibe and map discovery all work; checkout runs in demo mode until production Stripe keys are configured. The biggest known gap before real payments: server-side price validation (the checkout currently trusts client-supplied prices — fine for a demo, disqualifying for production) and order persistence beyond Stripe's own records.
It's a sandbox — but it's a complete one, and it taught me more about e-commerce product surfaces than any tutorial could.
