RaffClub

The brief

In spring 2025 RaffClub’s founders had an idea for an online prize draw platform and a quote from an agency to build it. They asked me to look over the quote as a technical adviser.

Within two weeks I’d replaced it with my own plan. It was phased so a public demo came first and the rest followed in stages, which meant the founders had something real to show long before the full build was done. I’ve been their interim CTO, and the only engineer on the product, ever since.

Launch, then a change of direction

The first version launched in December 2025 as a marketplace for prize draws on high-value items, with every item authenticated before it could be listed.

In 2026 the founders decided to focus on charities, community groups, sports clubs and PTFAs instead. I wrote the pivot spec, the build estimate and the design mockups, then rebuilt the product around fundraising. Every schema change was additive, so the existing marketplace kept running on the changing database right up to the cutover. The charity version went live in August 2026.

Money handled like a fintech

Every penny on RaffClub moves through a double-entry ledger, the same model banks and payment companies use.

Every movement balances. Ticket sales, refunds, platform fees, payment fees and payouts are all postings between ledgers. A posting is rejected unless its debits equal its credits. Each draw has its own escrow ledger, so the money it raises is ring-fenced from the first ticket sold.

Exact to the penny. Every amount goes through a single money type with banker’s rounding, so the platform fee and the payout always add up to exactly what supporters paid. A lint rule blocks plain arithmetic on money.

Refunds reverse the original sale. A refund is posted as the reverse of the sale it undoes, so the history shows exactly what happened, in order.

Safe under load and retries.

• Balance rows are locked in a fixed order, so simultaneous sales can’t overwrite each other’s updates or deadlock.
• Ledgers that must never go negative can’t be overdrawn.
• Every posting carries an idempotency key, so a payment notification delivered twice only moves money once.

Reconciled with the real world. Settlement reports from the payment provider are imported and verified, then matched against the money that actually lands in the bank.

Proved by tests. The tests cover four things:

• Every posting function balances.
• Replaying the same payment moves money exactly once.
• The maths survives property-based tests that try to break it.
• Every ledger’s stored balance equals the sum of its entries across a full raffle, on a real database.

Problems worth solving

A draw nobody can argue with. When a draw closes, the entry list is fixed and a hash of it is stored. The winner is then picked by Random.org’s third-party draw service, which publishes a record anyone can check. If the service is unavailable, the draw waits and tries again. There is deliberately no fallback to a random number generated on our own servers.

Never selling the same ticket twice. Tickets are held for ten minutes during checkout. A fast availability check runs first, a database constraint is the final backstop, and a scheduled job releases holds from abandoned checkouts.

Paying the cause automatically. Once a draw ends, the organiser’s share goes to their bank account without anyone at RaffClub having to press a button.

Rules built into the product. Where tickets can be sold, who is allowed to enter, and how a draw has to be described are decided by the product rather than left to a help article.

What I built

• Branded draw pages, ticket bundles and guest checkout with card, Apple Pay and Google Pay
• A host dashboard with live totals
• A share kit with QR codes and a printable poster
• A display mode for showing the total on a screen at fundraising events
• Automatic e-tickets and emails, with an admin tool for previewing them
• The charity waitlist site, and a test suite of more than 130 files

Beyond the code

As interim CTO, a lot of the work wasn’t code:

• Getting approved by the payment provider, then switching card and wallet payments to live
• Answering the solicitors’ questions about privacy and how the product actually works
• Designing the free postal entry process
• Writing the test plan and QA checklist before payments went live
• Moving the code and credentials into accounts the company owns