No.006 · Volunteer · training, materials + go-to-market · 2023–24
LIGHTNING ROD
An open-source Lightning point-of-sale for small restaurants. Four volunteers, a pizza place in a town of 1,200, and a server who had never heard of Bitcoin taking the order.
IN THE SHOP · Launch day at Five Star Pizza in Colon, Michigan.
- PROBLEM
- The integration worked, but the person on the register had never heard of Lightning, and an invoice that silently expires after fifteen minutes was behind two of the three failures.
- ROLE
- Volunteer, not on the build: the staff training, the operator manual, testing at the till during real service, and the launch marketing and pitch deck.
- RESULT
- Live at Five Star Pizza in Colon, Michigan, and in test at a second restaurant when I left the project. What I learned: a new way to pay succeeds or fails at the register, not in the code.
- Role
- Operator training · materials · in-store testing
- Year
- 2023–24
- Team
- Four volunteers, two on the build
- Stack
- BTCPay Server · Odoo POS (built by others)
- Status
- One restaurant live, one in test when I left
THE PROJECT
I met the team at a Bitcoin meetup. MI Lightning Rod was four volunteers building an open-source way for small businesses to accept Bitcoin: BTCPay Server connected to the Odoo point of sale, so Lightning appears in the payment list next to cash and card. Two of the four wrote the integration, and it already worked when I joined. I took on everything around it: staff training, materials, in-store testing and marketing. It went live at Five Star Pizza in Colon, Michigan, and was being tested at a second restaurant, Chadd's Bistro, when the local paper wrote about it.
THE OWNER AND THE PERSON AT THE REGISTER
The owner was already sold on Bitcoin: lower fees than card processing, no chargebacks, and money that settles to him. But he isn't the one using it. The user is whoever's on the register at 7pm on a Friday, five weeks into the job, who has never heard of Lightning and has four people in line. My work focused on that person, because one order that visibly stalls in front of a queue can undo the owner's enthusiasm.
WHY LIGHTNING PAYMENTS FAIL
A Lightning payment isn't like a card swipe. The terminal has to create an invoice, show it as a QR code, and wait for the customer's phone to pay it, and that invoice expires after fifteen minutes. So there's a hidden timer in the flow, and the two most common failures both come from it running out. The software doesn't say so.
MY ROLE
I wasn't on the build. I mapped the staff's steps against the existing screens, ran the register myself during live service, wrote the staff training, designed the launch marketing and the pitch deck for owners, and passed the failures back to the two developers to fix. On a four-person volunteer team, the layer between a working integration and a server using it on a Friday night was the part I could own.
TESTING IN A LIVE RESTAURANT
There's no staging environment for a Friday rush. Testing meant standing at the till of a working pizza place while real customers paid for real food. It's the most honest usability test there is, and the least forgiving, because every problem you find affects someone's dinner. It's also how you learn that the failure that matters isn't in the code: it's the moment the server gives up and reaches for the cash drawer.
THE OPERATOR'S MANUAL
What shipped to the restaurant in 2023, and what I would send instead.
I wrote an 18-page manual, co-branded with the restaurant, with every screen shown on both phone and tablet, because the floor used one and the counter used the other. It covers starting a session, building an order, taking payment, reading the orders page, closing out, and the three ways an invoice can fail. The owner liked it.
WHY A MANUAL WAS THE WRONG FORMAT
But a PDF gets read once, by the owner, sitting down. Nobody opens page sixteen with four people in line. Everything a server needs in the moment (invoice expired, payment pending, invoice not created) was at the back, after eleven pages they'd never need again, in a format that can't sit on the counter. The manual explained how the system works. What servers needed was help when something odd happens and there's a queue.
THE COUNTER CARD
The rework: the flow on the front, every failure and its fix on the back.
So I reworked it into one sheet that tapes to the wall next to the terminal. The front is the normal flow in six numbered steps, each naming the button exactly as it's labelled on screen, in the same colour. The back lists every failure the system can produce, titled with the words the server actually sees, each with a one-sentence fix.
EXPLAINING THE 15-MINUTE LIMIT
The back of the card starts with the fifteen-minute expiry, because two of the three failures come from it and the software never mentions it. Once a server knows a QR code expires, “print it when they're ready to pay, not when you start the order” becomes obvious. That one sentence covers most of the support questions the manual was written to answer.
“DID I ALREADY CHARGE THEM?”
The most stressful moment isn't a failure. It's not knowing whether a failed payment already took the money. The manual listed the four order statuses as a feature of the Orders page. The card uses them to answer that question: Receipt means paid, so don't run it again. Payment means the invoice is out and waiting. Ongoing means nothing was sent. Draft never reached the server.
WHAT THE CARD LEAVES OUT
Nothing about custody, Lightning, channels or price swings. A server doesn't need to understand Bitcoin to take a payment in it, and a card that explains it is too long to use. One line says the till does the conversion, the receipt total is in dollars, and any customer who wants to talk about Bitcoin should be sent to the owner, who always wants that conversation.
GOING TO MARKET
The launch event, the pitch deck, and the local press.
The pitch to owners isn't about the technology, so the deck starts with the sales channels a restaurant already has (the till, the website, invoices) and shows Bitcoin inside each of them. For the launch we held Bitcoin Pizza Night in Colon, which calls itself the magic capital of the world, built around watching the first order go through. Seeing someone buy a pizza with Bitcoin makes it real in a way a pitch can't.
WHAT WE LEARNED
The technology wasn't the hard part. BTCPay and Odoo worked, the owner was on board, and the customers who came for it loved it. The problems were a fifteen-minute invoice nobody had been told about and three error messages written for developers. Those are design problems, and cheap ones to fix.
WHAT WAS MINE
To be clear: other people built the BTCPay/Odoo integration and its code. The manual, the launch marketing and the in-store testing are mine, from 2023. The counter card is a rework I made for this case study: what I'd give a restaurant now. The team was four volunteers with day jobs. I've since left the project and don't know where it stands now.