My role
UX Designer, Builder
Duration
Q1-Q2 2026
Project type
Fullstack CMS, DB and App experience (Vibecoded)
Building Waypoints
Context
The Shift (in a perspective)
Waypoints started as a Google UX certification brief — design a tool for a community. The obvious answer before was
a scoring app. But the real problem wasn't on the field.
After every 3D competition I've competed in as an active archer, the results processing
looks the same:
1
paper scorecards collected
at the finish
2
manually sorted by category, cross-checked by hand
3
entered into a spreadsheet
The competition ends, and then everyone waits.
1 - 2 hours. Give or take.
Vibecoding made possible to build a live system — not just prototype one. My goal sharpened.
"Compress the evaluation window from hours to minutes, so the time people spend waiting
becomes time they chose to spend together."
Note:
Mentioned wait has a social layer — archers chat, have lunch, catch up with people they only see at competitions. That part matters. But there's a difference between choosing to stay and being stuck waiting for results that determine whether you placed.
When results take hours, some archers leave before the announcement. The moment feels smaller than it should.
System Overview
Two Sides of a Same Coin
Waypoints is now one live system, viewed through two interfaces. Each with a different purpose, aiming for a same goal.
Track Builder
Organizers use a CMS to build the competition — tracks, target categories, scoring rules — and publish it.
Waypoints App
Archers join by scanning a QR code, generated at publish, and from that moment both sides are reading and writing to the same real-time database. Then write and verify scores as they proceed in competition.
Two interfaces talk to each other from the moment of creating the event until each group has closed (e.g. written scores on each target).
Voting, scoring, verification — these actions happen entirely within the archer app, syncing in the background into the Live preview in the CMS.
The Organizer Side
Every field counts
"What made this side harder than it looked was that nothing in the track builder stays contained to the track builder. Every field set here has a consequence somewhere else in the system."
Designing the organizer side wasn't really about designing screens in isolation. It was about tracking a data contract between two interfaces built and tested separately, making sure nothing fell through the gap.
Note:
Not everything made it across cleanly. For example, the station shooting distance field exists in the track builder today, but doesn't yet feed into anything downstream. For V1, that gap was an acceptable trade-off; the field stays for future expansion, not as an oversight.
Challenge 1
Cognitive Load
The track builder is where competitions get built — and where a cognitive load problem showed up first.
A single long form covering competition details, track configuration, and review would have been heavy to fill out and heavy for the browser to handle.
I split it into three logical steps.
Define
Define the competition's text and structural details
Build
Build the track station by station
Preview
Review everything before publishing
Challenge 2
Build UI first, connect DB later
Building the system first with mock data, then connecting it to a live Supabase database, surfaced a major limitation. Connecting the two parts could be described as to try attaching string between photographs on a connection wall.
The process felt slow, and every connection spawned bugs and setbacks.
One example of a many is a bug where the scoring map pulled randomly generated placeholder targets instead of the actual configured ones. It's fixed now, but it exposed
a real cost of mockup-first development — early speed, deferred integration debt that has
to be paid eventually.
Feedback on V1
Trust doesn't scale (when it comes to strangers)
Once V1 felt stable, I organized a presentation for my local archery community, a deliberate session to show the current state and collect feedback before committing to a real outdoor test.
"The room" included experienced competitive archers, among them the same person who had tested the very first prototype two years earlier.
Meeting notes
Competition standards
Adding a Verifier logic to ensure trust of written scores as emphasis on treating each competition as high-stakes.
No users left behind
Adding possibility to add users without smartphones into the group. This ensures inclusive approach for anyone without a smartphone at hand.
Offline resilience
Outdoor 3D ranges run through forests and hills with patchy signal, offline resilience stopped being a nice-to-have and became a requirement.
Explaining the anecdote at the beginning, the original design for voting system assumed that whoever won the scorekeeper vote could simply write scores, no second check.
A reasonable assumption on paper, but it doesn't hold up once strangers are involved at a real competitive event. The room made that clear quickly. Each competition needed to be treated as high-stakes, e.g. two-part score writing — one archer records, another confirms.
Vibecoding Problems
As mentioned previously, several aspects proved my personal limits as a Noncoder. After connecting database and troubleshooting bugs my limits deepend with challenges in implementing three of the requirements established in meeting.
Implementing the verifier mechanic and the live dashboard behavior both broke in the same family of way, not because the rules were wrong, but because the system didn't agree with itself about what state it was in.
These challenges are the tip of the iceberg. I'll explain.
Challenge 1
The Race Condition
Early on, after the verifier mechanic was introduced, it started behaving backwards
in testing.
What went wrong? A flag called groupHasVerifier was read before the database fetch that would have set it correctly had finished, so the app defaulted
to false and acted as if no verifier existed
for groups that had one. A related bug had
the phone's local session caching an old scoring role, so someone could keep acting
as a scorekeeper or verifier even after their role had changed in the database.
What's the fix? Both bugs came down to trusting local or cached state over what the server actually confirmed. Fixing it meant applying the same discipline already being built for offline resilience
Challenge 2
The Self-Scorekeeper Conflict
Building this requirement collided with another feature I'd planned in parallel,
a "self-scorekeeper" mode, letting a solo archer record their own scores without
group voting at all.
What went wrong? Supporting both paths at once broke the permission system. Sometimes it locked the self-scorekeeper out mid-competition. Sometimes it did the opposite. At least once, a competition couldn't start at all, no one could write
a single score.
What's the fix? Self-scorekeeper is shelved indefinitely. Voting for a scorekeeper can no longer be skipped and anyone who doesn't participate, or runs out of time to vote, automatically becomes a viewer instead.
Challenge 3
Auto-close
When the last station on a scoring map was completed, the group closed automatically and the results screen rendered.
What went wrong? "Scored" and "verified" were treated as the same state. A group could close and the results screen could render before the verifier had confirmed a single target.
What's the fix? Auto-close was removed entirely. Scores still write to the database as they're recorded, but the competition-end screen only renders on the archers' phones once the last verification, confirming every remaining target, has gone through.
Current State
Working system (Awaiting field test)
Waypoints is now a feature-complete system that incorporates everything that came out
of the community feedback session in addition to already designed vision. The verifier requirement, manual archer entry, and offline resilience were all built and working.
Next milestone is a fake outdoor competition, e.g. full dry run under real field conditions, signal dropout included, before trusting the system to a real event. After that, the target is a genuine competition in August 2026.
Note 1:
The score-entry side now saves target images correctly, but the display side doesn't yet pull them reliably, a known bug, low priority, being fixed incrementally rather than blocking everything else for it.
Note 2:
Performance is the other variable, a single competition needs to comfortably support well over a hundred concurrent devices,
and that requirement multiplies if multiple competitions ever run on the system at the same time.
That load hasn't been stress-tested yet.
Ready to scale your product?