BAZARTY.COM (SUPABASE)

Handmade goods are one-offs — qty of 1 — so two parallel payments could 'sell' the same piece twice, and the Stripe webhook would move both orders to paid. The first reservation version (a 15-minute hold on a partial unique index WHERE status='active', error code 23505 as idempotency) looked fine — only a code review exposed the gaps: holds weren't released on errors (stranded holds), and the pending→paid transition itself had no collision guard. I closed it with an atomic state transition in a single RPC transaction, apply_paid_transition: a product lock plus a uniqueness guard, and a detected collision doesn't auto-refund — it flags the order needs_review with a double_sale_detected event; the money stays put, a human decides. Concurrency is settled by the database, not the client.

Seller onboarding ended with enabled status in Stripe while our payout_status hung on pending — the seller couldn't withdraw. The cause sat in a Connect nuance: a platform webhook doesn't receive account.updated events from connected accounts, and the new Stripe Dashboard no longer has a connect toggle — an endpoint with connect=true can only be created via the API, and it carries its own separate signing secret. It ended with two webhooks under the same URL and signature verification against both secrets in a loop until one matches. Plus the whole escrow machine: release transfers via source_transaction, a failed transfer rolls releasing→paid back, idempotency via processed_stripe_events, a buyer dispute halts auto-release, and a cron backstop forces resolution after 88 days.

After a period of fast 'clicked-together' development I discovered that the key escrow objects — the funds-releasing RPC, the Stripe events table, the Connect columns — existed only in the live production database, not in versioned migrations: the database wasn't reproducible from the repo, and an agent reading the code 'couldn't find the escrow'. Regaining reproducibility took several passes, because the first backfill covered the main objects and an audit surfaced more unversioned ones (payment_events, payout columns, RLS functions). The end state: idempotent migrations (applying on the live database is a no-op), a 'live database vs migrations' audit and a written decision that exactly one canonical database exists. An infrastructure-as-code lesson I won't forget: a schema that isn't in the repo simply doesn't exist.

This project is also a story of changing method. It began as a generative prototype in Lovable — fast, but with regressions, reverts and a drifting database — and ended in spec-first discipline: a planning package with phases F0–F6, a journal of twenty ADRs, a /loop whose definition of done includes code review and security review. I went from generating and clicking to measuring and closing — and that safety net immediately started catching real bugs: code review found, among others, a race in the search debounce (the alive flag set inside the timeout callback instead of the effect cleanup — an older request could overwrite newer results) and a pricing vulnerability where the client dictated the shipping cost; today the server computes the amount, calling the courier pricing itself, with a safe fallback that is never zero.