Own commits (of 241 total; rest are Figma auto-sync)
100+
Own commits (of 241 total; rest are Figma auto-sync)
⚡ Idea→ship
Web live ~1 week · App Store ~6 weeks
2026-02-03
First prompt · first working build
+6 days
2026-02-09
Web live (mechoose.store)
+36 days
2026-03-17
App Store approval
+120 days
2026-07-15
Latest commit
2026-02-03
First prompt · first working build
+6 days
2026-02-09
Web live (mechoose.store)
+36 days
2026-03-17
App Store approval
+120 days
2026-07-15
Latest commit
Idea → live web service ~1 week; App Store approval & release ~6 weeks (2026-03-17); also on Google Play. ~33 active days by git commits
01
Idea / Problem
First instruction: "I have no coding background, so I'm building the commerce app with Figma Make AI and GPT — but My Page keeps erroring and I'm stuck. Can you help?"
Original (KO): "기술이 없어서 Figma Make랑 GPT로 커머스를 만들고 있는데, 마이페이지에서 에러가 자꾸 나 막혀요 — 도와줄래요?"
I wanted a fashion shopping service for Thai consumers where you pick clothes, try them on virtually, and order right away. Beyond commerce basics (catalog, payment, orders, admin), the goal was to offer AI virtual try-on and stylist consultation in one place.
02
The Plan & Bar I Set
Planned the service scope and screen flow myself: catalog, orders, payment, admin
Ops bar: when info required for delivery (phone, address, LINE ID) is missing, don't block at checkout — collect it at app entry instead
Chose the tech stack with AI, optimizing for solo-operation speed: one web codebase wrapped to iOS/Android apps via Capacitor, API concentrated on serverless Supabase Edge Functions
03
Directing AI
Fig. mechoose-direction
Directing AI
01 First instruction
build the catalog, cart, and My Page screens, plus the API on edge functions.
02 What I checked
I placed real orders on the live site and found where payment stalled and where address entry produced typos and omissions.
03 Correction
I turned user problems into feature instructions — "let a stalled payment be resumed," "make the address autocomplete and fill in the postal code."
Actual instructions (excerpts)
›Don't overwrite everything — patch only what changed.Original전체를 덮어쓰지 말고 바뀐 부분만 패치해줘.
›Explain side effects before changing, and fix only after I approve.Original바꾸기 전에 부작용을 먼저 설명하고, 승인받은 뒤에 고쳐.
Fig. mechoose-03
Turning a problem into a feature, in words
Before
Orders with interrupted payment were left stranded
Users couldn't find where they stopped
My instruction (excerpt)
“Let people resume an order whose payment was interrupted”
Original결제가 끊긴 주문을 다시 이어서 결제하게 해 줘
After
✓ “Pending payment” banner + My page highlight
✓ Resume payment from where it stopped
04
Where It Got Stuck & How I Resolved It
Abandoned unpaid orders: Interrupted payments were left stranded. I directed AI to surface the "pending payment" state in a banner and on My Page and to add a re-entry flow that resumes from where the user left off, reducing drop-off.
Address entry errors: Hand-typed addresses had frequent typos. I added autocomplete that fills the postal code automatically, cutting delivery-failure causes.
Customer screens (Thai): pending-payment orders highlighted, with a path back to payment
Case 01
Orders with interrupted payments were left st…
!
Symptom
Orders with interrupted payments were left stranded and didn't convert.
›
How I described it
I want users to resume a stalled payment," described as a flow.Original결제가 끊긴 주문을 사용자가 다시 이어서 결제하게 하고 싶다"고 플로우로 전달.
↺
AI’s first try
A plain status label didn't help users find where they stopped.
◎
What I caught
The "pending payment" state had to be prominent in a banner and on My Page, and resume from the stop point.
✓
Fix
Added a re-entry flow, reducing drop-off.
⟲
Prevention
For interruptible flows, I design the "stop–resume" state in from the start.
05
Results
Running live on the mechoose.store domain
~8 weeks of active development (100 own commits; of 241 total, the rest are Figma auto-sync bot)
Frontend source of ~38,600 lines; edge function with 137 routes (single function)
Running features: unpaid-order re-entry flow, address autocomplete, AI virtual try-on
Admin panel — UI text translated to English for portfolio
Fig. mechoose-08
One web codebase → web, iOS, Android, serverless backend
FrontendReact · Vite · TypeScriptOne web codebase
WebVercelmechoose.store
App shellCapacitoriOS · Android
BackendEdge API (serverless functions)137 routes · orders, payments, admin
DataDB · Storage
AIAI virtual try-on (external API)
A one-person-operable architecture designed with AI: all API routes in one edge function, no servers to manage.
06
Retrospective
Features attached fast when I instructed by voice, but the early screen structure was packed into one file and got harder to change. Next time I'd set a bar from the start to break screen and state management into smaller, role-based pieces.
More screens · 3
Product
Cart
Checkout — PromptPay
UI shown in English for portfolio; product data is the live Thai catalog (seller photos blurred).
(01) Review
Honest Review
If a developer had built it
●Strong3
Feature scope — a full commerce service, running live
Shop, cart, wishlist, real card payments and refunds, claims and returns, inventory, reviews, a stylist app, an admin panel, 4 social logins, push and LINE notifications — live on the web, App Store, and Google Play.
Performance — main bundle 1.6MB → 454KB
Vendor code split into 5 chunks, the admin app loaded only when needed (664KB moved out), 5-minute data caching, lazy-loaded images.
Speed & cost — live web in ~1 week, App Store in ~6 weeks
~8 weeks of active development, ~51K lines, 100 own commits.
◐On par4
Security basics — on par with a small team
Admin check on every admin route, payment amounts re-checked on the server, origin allowlist, rate limiting, security headers, server keys never shipped to the app.
Release & ops — web + two app stores from one codebase
Vercel for web, Capacitor for iOS/Android, deep links, PWA, error screens with reference IDs.
Localization — Thai-first single market
245 translation keys; some hard-coded text remains.
Documentation — architecture and decisions recorded
A few figures in the docs had drifted from the code.
↗Next step (in progress)4
Testing & automation — no tests, CI, lint, or type checks yet
Every release was checked by hand on real purchase flows.
Plan → Payment and order logic first: 10–20 unit tests, then build + type check + tests on every commit.
Architecture — backend grew into one 6,299-line file on a single key-value store
137 API routes live in one file, and data sits in one generic store, so the database can't enforce relationships.
Plan → Split by domain (orders → payments → admin) and move orders and payments to proper tables with migrations.
Code consistency — loose typing and leftover copies
940 untyped (`any`) spots; fast iteration left three copies of server code and backup files.
Plan → Strict type checking as a release gate, removing `any` from payments first; delete stale copies.
History & monitoring — hard-to-trace commits, no alerting
141 of 241 commits are design-tool auto-sync; errors carry an ID, but nothing alerts me automatically.
Plan → Feature commits with clear messages kept apart from design sync; add error tracking and scheduled backups to the deploy routine.
