Overview
I planned and built a commerce service for US shoppers looking for Korean food, beauty, fashion, and home products. It currently runs on sample products, with admin features for swapping in real sourced products. The service name may change.
Problem
US demand for Korean products is scattered across many stores, and Korean stores don’t provide information in English or for US shipping. At the same time, handling payments, accounts, and orders as a solo project required a structure that could move into real operation, not “a demo that only looks convincing on screen.”
Approach
I reverse-engineered the public website of Weee!, a US Asian-grocery e-commerce company, into 15 MECE documents (service map, IA, per-screen UX, data model, operations, business model, target analysis, and more). I labeled each item as observation, evidence, hypothesis, or unverified, turned them into AI execution prompts, and built with Claude Code. Distinguishing “screen demo / feature demo / operable service,” I designed the safeguards first: demo orders are always marked as demos, the server recalculates amounts, and idempotency keys prevent duplicate orders. I chose the payment provider based on cost and entity requirements: I ruled out Stripe because Korean businesses can’t sign up, and checked PayPal’s effective fee (about 7.9%) as well as the hosting terms’ restrictions on commercial payments.
Results
Built with Next.js 16, React 19, Supabase (RLS, MFA), PayPal, and Vercel: 130 commits in 8 days and about 15,000 lines of TypeScript. It includes browsing by store and category, ZIP-based estimated delivery dates, English/Korean switching (about 440 UI strings), TOTP 2-step verification, and an admin console with audit logs. Automated accessibility checks across 14 screens × 4 widths = 56 runs found 0 violations, and there are 0 npm vulnerabilities. It runs on 75 sample products, with no real payments, real shipping, or user metrics yet.
Lessons Learned
The quality of the reverse-engineering documents set the pace of implementation. When building a demo, the first thing to design is not features but “safeguards that keep the demo from leaking into real transactions.” The next task is to finalize the business model (direct purchase vs. purchasing agent) and sourcing contracts.