What an AI app builder did and didn't do for our real-time multiplayer game with Lightning payouts

Clixel Posted on Oct 15 AI-assisted At Clixel we run a small browser game. Everyone shares one grid with one fast white pixel. Every missed click adds 0.01 sats to a shared pot, and the first person to click the pixel takes it. The winner claims the pot over Lightning by scanning a QR code with a phone wallet. Here's how it's put together and where it fought back. The stack Front end: Lovable, an AI app builder, generating React from our prompts. Backend: Supabase (Postgres, edge functions, scheduled jobs). Payouts: LNbits, using LNURL-withdraw so a winner just scans a QR code. What the AI handled well The board UI and most of the edge-function boilerplate. Fast iterations on layout and copy. What still needed a human Reviewing every database change before it went live, and checking the result. Making sure the payout keys pointed at the right wallet. Testing real claims on our own phones. The hard part: paying people Each win gets one single-use withdraw link, shown as a QR code that stays valid for 15 minutes. Getting that flow reliable on phone wallets took more work than the game itself. A lesson we learned the hard way: don't ban by IP What went wrong: our first anti-bot rule banned any IP where several accounts showed up in a day. Who it hit: real players on phone networks, offices and dorms, where lots of people share one IP. They got locked out, sign-up included. What changed: we lifted those bans, a busy shared IP now only pauses new guest sessions for a while, and abuse is tracked per account instead of per network. Two questions for you How do you keep bots out without punishing people on shared networks? If you've synced one moving target across lots of browsers, what did you use? It's running here if you want to see it: https://clixel.io/play