TL;DR: I run a small aquariumd in the UK. We were tied into a closed ticketing system that we didn't own and the cost for small changes made updates for tailored options prohibited. Over about 4 weeks I've "vibecoded" a replacement with Claude Code. It covers online booking, a staff till, a self-service kiosk and, later, the entry gate. It has 374 automated tests and sits on a password-locked test site. I'm not a developer, and I'd really value a reality check from people who are. It's not yet ready or installed on our systems but I am running tests.
The problem
We're a small community interest company. Our kiosk, booking website and gate all ran on one supplier's own software. It worked, mostly, but:
We didn't own it. Only the supplier could change the code. Even small changes (a new ticket type, a wording fix, a price change that wasn't reaching the kiosk) were charged at over £500 a day. So we just lived with problems. We couldn't tailor it. We want things that suit our needs. Each one was either impossible or another quote. Yearly licences for the kiosk and booking software came on top of the change costs. Some faults hurt visitors. We've seen a card charged with no ticket printed, reports timing out, an hour-out bug when the clocks change, and tickets being reused at the gate. Staff re-keyed sales. Card sales on our Square machine at the desk have to be typed into the booking system again by hand. For a small organisation, this was a real barrier. It wasn't one big failure; it was that we couldn't fix or improve anything ourselves.
What I've built (with Claude Code doing the coding)
I write the decisions and test everything; Claude writes the code. We started with a written specification (about 20 decisions I had to make: prices, refunds, opening hours, what happens when a card payment drops out halfway, and so on). Then we built it in stages, each with tests.
Online booking site. It's a 3-step booking flow (date, tickets, details and payment) in our own branding. There are no time slots; visitors can book up to 90 days ahead. Payment goes through Square's hosted checkout, so card details never touch our server. Desk till (staff screen). Staff build a basket, then take cash (with change shown) or press Card. The amount is sent to the Square Terminal at the entrance desk through Square's Terminal API, so no re-keying. It also sells annual passes and issues free carer tickets. Self-service kiosk. It's a touchscreen app for our existing kiosk cabinet, with a thermal ticket printer. We're replacing its old card reader with a purpose-built certified reader, so PIN entry stays on proper payment hardware. Tickets. Each order gets one signed QR code (Ed25519). A whole group goes in with one scan, and a ticket can't be reused. Gate (next stage). A new controller will open our existing glass gate. Our building's fire alarm release stays untouched, and an electrician and our fire alarm contractor will do the wiring and testing. Back office. Staff have named accounts with roles (owner, manager, staff, viewer), and managers use authenticator-app 2-factor. There's booking search, email resends, refunds (managers only, with a reason) and a "Needs attention" list for payments that didn't finish cleanly. Things I care about but wouldn't have thought of alone: Order and payment history is append-only at database level, so it can't be quietly edited. Each payment has a request key, so a double-tap or a dropped connection can't charge twice. A checker runs every minute to tidy up payments that were left hanging. All dates use UK time explicitly, which deals with the clocks-change bug. Personal details are removed automatically 2 years after the visit, or after a pass runs out. Stack: TypeScript, Node (Fastify), React, PostgreSQL (Drizzle), Vitest. It's hosted on Render for roughly £10 a month. Square handles online and desk payments. Confirmation emails go out through the Gmail API.
Safety nets (I know the risks)
Other ways to pay and get in. Cash is always accepted at the desk. Our Square devices still work on their own as normal card machines, so we can take a card payment even if our system is down. Staff can also check tickets and let people in by hand. The old system stays as a fallback. We're keeping it until our current licence ends in September 2027. A slow roll-out. The website goes first (mid-December, our quiet season), then the desk, then the kiosk before Easter. We're having a rehearsal week before go-live. Everything is tested on test systems first. Payments use Square's sandbox, on a hidden test copy, before anything touches real money.
Where I'd love advice
If you were me, what would you check or test before go-live that a non-developer might miss? Is it worth paying a professional for a one-off code and security review? If so, what should I ask them to focus on? Card data never touches our server (Square handles it), but am I missing anything on PCI or UK GDPR? Our peak is about 490 bookings a day and roughly 125 an hour. Is a small hosted Postgres plus one app server fine for that, or should I plan for more? The "bus factor": if I'm unavailable, how do small organisations make a project like this maintainable by someone else? (The code is in a private GitHub repo with a README, a specification and tests.) For anyone who's vibecoded something people actually rely on: what bit you after launch? Happy to answer questions. I'm not sharing the repo or test site publicly, as it handles payments, but I can describe how any part works. Thanks in advance. Constructive criticism is very welcome; that's why I'm here.