Solomon Okeke Website Platform

Registration went through a generic Google Form with no payment collection built in. Booking requests came in by email with no visibility into whether a date was already taken, so double-booking was a real risk rather than a hypothetical one. Check-in at events meant a paper list. And several thousand event photos sat scattered across Drive folders from years of past programs, effectively invisible to the site.

The site needed to look like a speaker's brand and behave like the operations layer behind one.

Every event used to need a code change to add a registration question. Now Event.formFields holds an array of question definitions; label, type, required flag, helper text, an optional "Other: ___" write-in, and staff build the form per event from the admin portal. Answers land in a flexible key-value map on each registration instead of fixed columns, which is what makes the per-event response dashboard possible: pie charts for single-choice questions, bar charts for checklists, generated from whatever questions actually exist on that event rather than a schema decided in advance.

The booking form doesn't just collect a date. It enforces two constraints, both server-side and client-side: five bookings maximum per day, and a two-hour minimum gap between any two so Solomon can actually travel between venues. Accepting a booking authenticates against Google's Calendar API through an OAuth2 refresh-token flow and creates the calendar event with reminders automatically. Decline or delete the booking and the calendar event goes with it, no orphaned entries left behind.

Payment for a booking runs the same logic one layer further. Accept a request with a price attached and the system generates a one-time token, gives it a 24-hour deadline, and emails the client a link. That link lives on a payment.solomonokeke.com.ng subdomain that's really the main site's own React Router, pointed at an unlisted /pay/:token route. A background sweep checks every 15 minutes for tokens whose deadline passed unpaid and flips those bookings to expired on its own.

The check-in scanner originally ran on a popular third-party QR library. On certain Android/Chrome combinations, the camera feed would show for a second and then go solid black, camera technically active, nothing visible on screen. Patching the library's configuration didn't fix it. Replaced it entirely with a scanner built directly on the browser's own getUserMedia and BarcodeDetector APIs, with a jsQR canvas fallback for browsers without native barcode detection. Staff can also type the code by hand if a phone's camera won't cooperate that day.

Hosting years of event photography directly would have meant real storage and bandwidth cost on shared hosting. The gallery instead stores only Google Drive folder links per album. Images get fetched on demand through the Drive API with a public read-only key, so adding an album is sharing a folder link, not running an upload pipeline.

Getting there also meant re-curating 46-plus historical albums down to only photos that actually contain Solomon, since reviewing several thousand images by hand wasn't realistic. That ran through a Python face-recognition pipeline: DeepFace for matching, Drive OAuth for write access, images downscaled and processed in parallel to keep the runtime bearable.

Videos store a YouTube ID and embed. Nothing self-hosted. Same reasoning as the gallery: playback, bandwidth, and delivery become YouTube's problem, and the admin side only manages titles, descriptions, and featured or short flags.

Event tickets and booking payments both run through Paystack: the public key drives client-side checkout, the secret key does server-side verification before anything gets marked paid. Cutting over from test keys to live keys surfaced a specific failure mode: "transaction reference not found" on verify, even though the customer had genuinely been charged. Paystack throws that exact error when the secret key verifying a transaction doesn't match the environment the reference was created in.

The measurable shifts since the system replaced the old form-and-email workflow: