FERMENT

I designed the payments on a zero-trust-in-the-client principle: the price is computed server-side (never read off the DOM), the payment intent is created in an edge function with the amount from the database, and the Stripe webhook verifies its signature before closing the order. I also took a real incident on the chin — the Stripe webhook pointed at an old Vercel URL from an earlier project iteration, so orders weren't closing despite successful payments; I documented the diagnosis and fix (rerouting to Supabase) in .lovable/plan.md. Ever since, webhook routing is my first suspect.

Shipping turned out to be a series of ambushes on two fronts at once. The Furgonetka API needed non-standard authentication — the working variant is OAuth with Basic auth of client credentials plus grant_type=password, and the correct parcel format (InPost's fixed 'size B' as a universal dimension for clothing) before pricing returned anything at all. Meanwhile the InPost map widget returned the chosen point's postal code in a random field — postCode, post_code, postalCode, zip — or not at all, sometimes only inside a descriptive address. The readout is now defensively bulletproof: it concatenates a dozen candidate fields into one string, runs a \d{2}-\d{3} regex, and as a last resort scans the whole object via JSON.stringify. Eight commits of mounting desperation in their names ('read' → 'parse' → 'extract' → 'improve') taught me never to assume the shape of someone else's data.

I wired a complete, playable retro arcade game into the shop — 'FERMENT RUN', a self-contained 3,194-line vanilla-JS canvas file with no game framework. The engine has its own bitmap font (each glyph a 5×7 grid encoded as a string, rendered pixel by pixel), a delta-time loop making speed independent of the device's frame rate, and a virtual keyboard for mobile — refined across fixes, because touch 'released' the arrows differently than a keyboard. The leaderboard is server-side: having no supabase-js client, the game hits the Supabase REST API directly with the anon key, and a ten-plays limit lives in a cookie (honestly: a UX barrier, not security). The game tile opens a fullscreen iframe with a four-phase CRT shutdown animation — if terminal aesthetics, then all the way.

Instead of static photos, some products are rotating 3D models — and the whole pipeline had to be operable by a non-technical admin. The insert form accepts a GLB/GLTF file, uploads it to Supabase Storage and exposes twelve transform controls: scale, position and initial rotation per axis plus independent auto-spin toggles on each of the three axes — with a live preview. In the shop grid, react-three-fiber reads those parameters and spins the model in useFrame with delta-time, while a preloader fetches all models ahead of time so the grid doesn't stutter on first render; the 3D component itself is lazy-loaded, so a client with no models never pays for three.js. Mobile needed its own round of fixes — WebGL on phones forgives far less.