Leo Hydra Studio

It's a real business at a real cadence. Every drop sells out inside a week of going live. Originals are priced on inquiry but they move through the same operator, the same calendar, the same warehouse. One pipeline, two SKUs.

A production-grade Next.js 14 e-commerce platform that I architected and wrote from scratch:

• Dual-rail checkout: USDT-on-Polygon (verified on-chain via ethers plus a Vercel Cron scanner walking USDT Transfer events every ~2 minutes) and bank transfer (admin manual confirm, UTR uniqueness enforced at the DB via partial unique index).
• Micro-offset payment discriminator: every crypto order gets a unique 1 to 999 µUSDT offset added to its expected amount, enforced by a partial unique index on payments(expected_amount_micro) WHERE status='initiated'. Two pending orders with identical cart totals can never collide on-chain. Reserved and released by status-change triggers.
• Race-locked payment confirmation: confirm_payment_atomic does SELECT … FOR UPDATE on the order row at the very top, then status-guarded UPDATEs to serialize against admin-cancel, auto-expire, and cron-expire (migration 031). Three cascading triggers on orders handle payment-row expiry, stock release, and micro-offset release in lockstep.
• Transactional email pipeline: Resend-backed sends across six lifecycle email kinds (order confirmation, bank instructions, bank reference submitted, bank confirmed, order recovery, studio notifications). Every send writes a row to an append-only order_email_events audit table. Admin "Resend" UI is synced with the API route mapping so what's offered and what's sent stay in sync.
• Meta Pixel + Conversions API across every conversion surface (checkout, inquiry / contact / project-request forms, newsletter, product pages, site-wide PageView), all dedup-aware via a shared eventID, PII hashed SHA-256 per Meta spec. Browser PageView uses navigator.sendBeacon with a fetch keepalive fallback.

The race locked confirmation, the micro offset discriminator, the cron scanner. These look heavy for a single operator studio. They're not. They exist for the same reason real e-commerce shops use them. Every drop launch is a 7 day rush window where concurrent purchases are realistic. On-chain payments settle through a public mempool, and the order of events is not under your control. A payment confirmation bug at any volume above zero is an unrecoverable customer trust event.

The engineering is sized for the worst case minute of any given launch day, not the average minute. At low traffic these patterns cost nothing. At launch traffic they're the difference between "shipped clean" and "manually reconciling for a week".

The full breakdown: ~12 Postgres tables (orders, order_items, payments, bank_transfer_payments, crypto_payments, products, leads, newsletter, order_email_events, payment_micro_reserved, order_scan_throttle, rate_limit_buckets). ~30 forward-only migrations applied via Supabase SQL editor, with verified live-DB drift checks against nightly pg_dump backups. Three documented security audit rounds harden rate limiting, brute-force lockout, CSRF Origin checks, PII redaction, and three isolated HMAC secrets + CSP and security headers in next.config.js.

Originals don't run through the checkout above. Unique pieces are priced on inquiry, captured into the leads table, and routed to the studio manually. Two commerce models, one codebase.

Run Meta ad campaigns end-to-end. Manage limited-edition print production with printing houses. Coordinate fulfillment from the Dubai warehouse. Hire and direct video editors. Sound design and multi-platform posting (Behance / Tumblr / Instagram). Scale Reels generation with modern creative tooling.