How might we compress the evaluation window after a 3D archery competition, so the time people spend waiting becomes time they chose to spend together?
I could not code.
Everything I built was done so using vibecoding on Lovables platform. As base I used my designs from Figma, tested in Phase 1 (see Waypoints Phase1). This approach made building fast, but later debugging slow, and I document the cost below.
The unstable environment.
3D ranges in competitions run through forests and hills with patchy signal. Offline resilience started as a nice-to-have and became a requirement.
Scale.
One competition needs to support well over a hundred concurrent devices. This scale has not been stress-tested yet. Small scale test with under 20 concurrent devices took place in July 2026, with positive results.
Trust.
Scores decide placements. Strangers at a competitive event will not accept a system they cannot verify.
Understanding how competitions work
The starting point is lived experience, both as archer and supporting organizator. At every 3D archery competition I have competed in, results processing looked the same. Paper scorecards collected at the finish, sorted by category and cross-checked by hand, then typed into a spreadsheet. Everyone waits, from 1 to 2 hours.
Feedback from community
The next input was a deliberate feedback session with my local archery community after finishing the first functional version, held before any real outdoor test. The room included 6 experienced competitive archers, among them the person who tested the very first prototype two years earlier. This session drastically improved the final changes in current version (see Direction).
The wait has a social side: archers chat, eat, and catch up with people they only see at competitions. That part matters. But choosing to stay is different from being stuck waiting for a result that decides whether you placed. When results take hours, some archers leave before the announcement, and the moment feels smaller than it should.
First direction: A scoring app.
The Google UX certificate brief asked for a tool for a community, and the obvious answer was an archer-side scoring app. I built that prototype first (see Phase 1).
Reframing: The real problem is not on the field.
Time is lost after the last arrow, in the organizer's paperwork. Vibecoding made it possible to build a live system instead of only a prototype, so I widened the scope to two interfaces sharing one live data model: an archer app and an organizer CMS.
The decision the community overturned.
My first voting design assumed that whoever won the scorekeeper vote could simply write scores, with no second check. On paper, reasonable. However, with strangers at a competitive event, this approach might it fell apart quickly. The result was a two-part rule. One archer records, Another confirms. Everything in real time to avoid any conflicts.
The session also produced two more requirements. Archers without smartphones must be addable to a group, and the app must work offline.
Scoring screen. Figma Prototype on Left, Lovable Version on Right
1. Two interfaces, one live system
When the organizer publishes a competition, the system generates a QR code. Archers scan it to register, and all voting, scoring and verification happen in the archer app and update the organizer's live dashboard instantly.
2. Split the track builder into three steps
One long form for competition details, track configuration and review would have been heavy for the organizer and for the browser. To prevent excessive cognitive load, I've split the track builder into 3 parts. Define, Build, Preview.
CMS Track Builder Prototype.
3. A verifier for every score
One person writing scores with no check does not hold up at a high-stakes event. The scorekeeper records and a verifier confirms or fixes each target. After finishing the competition flow, the competition-end screen only appears once the last verification is done.
4. Offline queue and no-smartphone entry
Signal drops on the range, and not everyone carries a smartphone. To address these known real life issues, Targets are cached for offline use, pending writes queue and flush after reconnecting, and an archer without a phone can be added manually to a group.
Adding the teammate to the group (Left). Offline resiliency (Right)
Building the system first with mock data and connecting a live Supabase database later surfaced real costs. Early speed bought integration debt. Every connection needed its own prompt and spawned its own bugs. For example, the scoring map pulled random placeholder targets instead of the configured ones. It is fixed now, but it shows what mockup-first development costs.
The three bugs that taught me the most all had the same root. The system did not agree with itself about what state it was in.
1. The race condition.
After I added the verifier mechanic, it behaved backwards in testing. A flag, groupHasVerifier, was read before the database fetch that sets it had finished, so the app acted as if no verifier existed. A related bug let a phone keep a cached scoring role after the database had changed it. Fixed logic now trusts what the server confirms, not local state, the same discipline I was already building for offline mode.
2. The self-scorekeeper conflict.
I had planned a mode where a solo archer records their own scores. Supporting it alongside voting broke permissions. It often locked people out and at least once stopped a competition from starting at all. I had to shelve this mode indefinitely. Voting can no longer be skipped, and anyone who does not vote in time becomes a viewer.
3. Competition Auto-close.
"Scored" and "verified" were treated as the same state, so a group could close and show results before the verifier had confirmed a single target. Fixed by removing auto-close feature. System waits for organizer to close the competition.
Awaiting Field test
Planned August 2026 competition did not use the sollution, because of rulles restriction. Competition was part of the series of tracks, which prohibited to use apps.
Solved organizers pain point
Current system solves main pain point, results generation in competitions. Instead of manually calculating scores from paper tables is now possible to get results ready in under a one minute.
<5 minutes | <1 minute | 150+ |
|---|---|---|
Time to publish a competition | Time to generate results | Devices per competition* |
Currently I´m looking for a way to test the large scale concurrency and implement the app into existing competitions. If you´re an organizator of archery competition planned in 2027, send me an email on lukas.ruckschloss@gmail.com
Competition Flow. From scanning the QR code to Writing scores.
