WayMark

𝐄𝐥𝐞𝐯𝐚𝐭𝐨𝐫 𝐏𝐢𝐭𝐜𝐡

WayMark — one record per participant, captured once at registration, reused for check-in, jury scoring, certificates and reports instead of retyping the same details five times.

𝑨𝒃𝒐𝒖𝒕 𝒕𝒉𝒆 𝑷𝒓𝒐𝒋𝒆𝒄𝒕

𝑾𝒉𝒂𝒕 𝒊𝒏𝒔𝒑𝒊𝒓𝒆𝒅 𝒖𝒔 : We kept noticing the same pattern at every event we'd helped run or attended: a registration form, then a spreadsheet, then a messaging group for reminders, then a printed attendance sheet, then a feedback form, then a certificate template, then a report stitched together at the end from all of it. None of those steps is hard on its own. What actually eats the time is the hand-over between them — someone copying the same name and email into the next tool, again and again. A waymark is the marker that tells a traveller where they are on a route without them having to ask. That's basically what we wanted the participant record to be: one fixed point that every later stage reads, instead of asking the person, or the organiser, again.

𝑻𝒉𝒆 𝒑𝒓𝒐𝒃𝒍𝒆𝒎 𝒘𝒆 𝒘𝒂𝒏𝒕𝒆𝒅 𝒕𝒐 𝒔𝒐𝒍𝒗𝒆: Our core question was: how do you join the full event lifecycle into one flow, where a participant's data is captured once and then reused for verification, attendance, communication, feedback, evaluation, certificates and reporting, with as little manual admin as possible? It's not that there's a shortage of forms or spreadsheet tools — there isn't. The gap is the connection between them, and right now a person has to maintain that connection by hand. For judged events it gets worse: marks get written on paper score sheets, totalled by hand, and typed in a second time before a result can even be published.

𝑾𝒉𝒂𝒕 𝒘𝒆 𝒅𝒆𝒔𝒊𝒈𝒏𝒆𝒅: WayMark is an event platform where an event is one connected process and a participant is one record inside it. A few decisions shape the whole thing:

Two roles, not a hierarchy. A User can both attend events and create them, and an Admin controls platform quality by approving what gets published. We looked at adding organiser, moderator and volunteer roles and decided against it — every extra role adds a permission check without helping the actual work. Type-aware event creation. When someone creates an event, the first question is what kind of event it is, because that decides which questions are worth asking. A hackathon needs team size, tracks and a judging rubric; a meetup doesn't. The event-type definitions are data the backend holds, not hard-coded forms, so a new type is a new field definition rather than a new form to build. A jury module that's more than two bullet points. For judged events, the creator invites judges by email, sets a rubric with weighted criteria, and each judge gets a single-use, time-limited link — no account, no password. On the day, the judge scans the same QR that got the participant through the door, scores against the rubric, and the platform computes the weighted total, the rank, and flags the spread between judges so a wide disagreement gets looked at before results go out. Rule-based everything that matters. Attendance, certificate eligibility and competition results are never inferred — they come from a check-in record, a rule the host set, or published weights applied to submitted scores. If a participant asks why they didn't get a certificate, there's a real answer. Certificates that can actually be checked. Every certificate gets a non-sequential ID and a QR code linking to a public verification page that shows whether it's valid or withdrawn. A PDF alone can be edited by anyone; a certificate a single scan can check is a lot harder to fake.

𝑯𝒐𝒘 𝒘𝒆 𝒂𝒑𝒑𝒓𝒐𝒂𝒄𝒉𝒆𝒅 𝒊𝒕 𝒕𝒆𝒄𝒉𝒏𝒊𝒄𝒂𝒍𝒍𝒚 ! We picked a stack we could actually finish and defend: React on the frontend, Flask for the backend, and Supabase for Postgres/MongDB Atlas, auth and storage. The principle we kept coming back to was "the browser displays, the server decides" — every rule around permissions, event state and eligibility is enforced in Flask, with Postgres Row Level Security as a second, independent lock underneath. AI sits behind a single adapter with three operations — generate text, summarise, and map a request to a pre-built query — and it never writes to the database directly or decides anything that should be a fact: not attendance, not a score, not who gets certified. We deliberately left out microservices, a message broker and container orchestration. A scheduled job inside Flask covers the automation we need, where reminders, score-locking and certificate generation fire because the event reached a state, not because someone remembered to click a button.

𝑾𝒉𝒂𝒕 𝒘𝒆 𝒍𝒆𝒂𝒓𝒏𝒆𝒅!!!

Writing the data model forced us to actually commit to decisions we'd been hand-waving — like what a jury member is, permission-wise. We went back and forth on whether they needed their own account type before landing on scoped, single-use guest access, which turned out to be simpler and safer at the same time. We also learned that naming the two things we weren't going to build (a real-time chat feature, self-hosting, anything requiring a trained model) was just as useful as naming what we were building, because it kept the scope from quietly growing.

𝑪𝒉𝒂𝒍𝒍𝒆𝒏𝒈𝒆𝒔 𝒘𝒆 𝒇𝒂𝒄𝒆𝒅 The honest one is that we're four people with limited time, and the full event lifecycle is too much to build correctly in one go — so Round 1 is the design, the architecture and the data model, not a working build. We also had to think carefully about things that sound simple but aren't: what happens if the same QR gets scanned twice at a busy check-in desk, or if a provider's free AI tier runs out mid-event. Our answer both times was to make sure the feature degrades instead of breaking — a repeated scan gets refused rather than double-counted, and the whole platform still runs end-to-end if the AI key is missing.

𝑾𝒉𝒂𝒕 𝒘𝒆'𝒅 𝒊𝒎𝒑𝒓𝒐𝒗𝒆 𝒏𝒆𝒙𝒕 Round 2 is where this becomes a working prototype instead of a design document: authentication, event discovery, event creation and approval, registration with profile reuse, QR check-in, and the jury panel are the essential build. The AI drafting features, feedback summaries, and the maps/venue picker are stretch goals we'll add once the essential flow is solid. If we only get through the essential list, the project still proves the thing we actually care about — one record carried through the whole lifecycle, an Admin review step, jury scoring that produces a defensible result, and certificates anyone can verify.