In my recent dive into the world of the Lightning Network, I built a simple project—a React-based betting game. During the project, I learned a couple of things that I’d like to share in this post.
First of all, I was surprised by how supportive ChatGPT is from a technical point of view. It helped me scaffold the project, recommended specific technologies, and even suggested an appropriate editor. On the other hand, I was unpleasantly surprised by the Lightning Network—how unintuitive it still is from the user’s perspective. But first things first.
I had a rough idea for a one-evening project built on the Lightning Network, so I asked ChatGPT to generate a list of ideas. I chose a dice roll game where:
- Players bet on a number by making an LN payment.
- If they win, they take the entire pot by claiming it with LN.
- If they don’t win, their sats contribute to the growing pot for the next round.
Simple enough—but since I didn’t have any experience with these kinds of technologies, I had to rely on ChatGPT again. It proposed using React and Vite as frontend frameworks, Alby or LNbits for integrating Lightning payments, Supabase or Firebase as a minimal backend solution, and Vercel, Replit, or Netlify for deployment.

Since I wanted to use a mobile wallet instead of a browser extension, the payment solution was narrowed down to LNbits. I also stripped out the need for a backend for the MVP and stuck with React useState only.
Bootstrapping the project was very easy. It basically involved installing a few dependencies via npm and adding an admin key for LNbits. That could be a security issue without proxying the calls through a backend, but I decided to accept the risk for the MVP and the small satoshi amounts in the demo wallet.
After picking a lightweight editor (I went with Zed since I didn’t want to use VSCode or WebStorm), we had to do a couple of iterations over the code to get it running and eliminate all the linting complaints. But it was running and accepting payments—all within an hour! One missing piece was adding support for claiming winnings, but we quickly solved that as well.
Here I’d like to pause: the user experience while using Lightning payments is still quite harsh, and I feel that’s something preventing broader adoption by regular users. I had been using the Phoenix wallet for a while—but only for sending payments. Now I needed the players to receive payments as well, which meant gaining a basic understanding of how Lightning actually works, including generating BOLT11 invoices. That’s quite easy with Phoenix, but still, the user has to request a specific amount—raising questions like, “What if I request too little or too much?”
So I decided to implement LNURL-withdraw, which removes the need for players to create invoices. After a bit of work, I had it running—players could now claim winnings by simply scanning a QR code! Again, not super intuitive, but functional. I can imagine a future where wallets have a single button (e.g., “Scan QR”) for both payments and withdrawals. That would improve the user experience dramatically. But with Phoenix, the user has to first tap “Receive” and then click a tiny icon in the corner—not very user-friendly.

Anyway, let’s move on. I had it running locally, linted, code-reviewed, and ready to deploy. From the options ChatGPT suggested (Replit, Netlify, Vercel), I chose Vercel (based purely on gut feeling, sorry 😄). It connected to the project’s GitHub repo and was able to fetch and deploy the code on demand or on push to a specific branch. So easy! That means the project is public and running—though it does have some security issues without a backend. But that’s a story for another time, if I ever get to it.
Conclusion
I used generative AI for ideating, implementing, and deploying a simple project. I was surprised by how easy it was—originally I wanted a weekend project, but I actually managed to finish it in a single evening. I can now easily imagine no-code or multimodal programming becoming a reality.
Still, user input is necessary—at least for reviewing, refining incorrect URL calls, and challenging odd bits of generated code (linting alone isn’t enough). As for the Lightning Network, I was disappointed by how unintuitive it still is, especially considering it aims for mass adoption. Perhaps it’s not the right protocol for widespread Bitcoin use—yet. Looking ahead, I hope it matures to the point where, like the internet today, people can use it without needing to understand the ISO/OSI model. The future looks bright!