Repeated transcription caused preventable errors
At a major Georgia honey show, secretary errors caused serious recordkeeping problems. The process required people to copy the same entry numbers across labels, judging sheets, and result records while working under time pressure.
The traditional process
- An exhibitor arrives with entries and an affidavit.
- A secretary assigns entry numbers and records the relationship between each number and entrant.
- The numbers are manually copied onto multiple labels.
- Judges write entry numbers on comment cards and results sheets.
- Secretaries interpret the handwriting and enter those numbers again.
- Entry numbers are mapped back to entrants and placements.
Every handoff creates another failure mode
- An incorrect, reused, or nonexistent entry number
- A result saved against the wrong category or entrant
- An award given to someone who never entered the category
Check entry numbers before saving results
The system rejects invalid actions at the point where they occur.
The system assigns random four-digit numbers from 1000 through 9999, prevents reuse, and blocks duplicate entries. It reserves separate number pools so several secretaries can work at the same time.
When a secretary records an award or result, the number must exist in the relevant category. An invalid number cannot be saved. The validation happens in the context where the error can still be corrected quickly.
Keep paper in the workflow
Honey shows still depend on physical jars, labels, and paper records. The software reduces how often secretaries have to remember and recopy information as those materials move through the show.
The application integrates with Dymo label printing and tracks how many labels each category requires. At check-in, it assigns a valid number and prints the correct labels automatically. The secretary no longer has to remember and repeatedly copy that number.
Organize the interface around the day of the show
Show Mode gives secretaries a workspace built for running the event.
Its top-level phases are Check-in, Judging, Awards, and Reports, matching the order of work during a show. Separate entry and entrant screens let secretaries monitor the event while entries remain anonymous during judging.
Check-in
- Enter an exhibitor or reuse and autofill returning-entrant details
- Capture eligibility for special awards while the entrant is present
- Record entries, notes, and physical check-in state separately
- Assign numbers and print labels automatically when enabled
- Review entries before the workflow moves forward
Judging
Judges continue using paper because it works well at the judging table. Secretaries enter the results, and the application checks that each number exists in the category before accepting it. A digital judging interface would add work without solving the transcription problem.
Awards and reports
The system calculates deterministic awards, validates judgment-based selections, and produces a placement list and post-show reports.
1 · Entrant details
3 · Finalize entries
Calculate rule-based awards and check selected awards
The system handles awards differently depending on how each winner is determined.
The system calculates
- Sweepstakes based on award points, with a visible tracker
- Grand champion logic
- Club awards based on entries or points
- Defined tie-breaking logic
Judges choose
Judges select awards such as Best in Show and Best in Honey. A secretary enters the chosen number, and the system checks that the entry is eligible for that award.
Make the system configurable for other shows
I designed the application for more than one event, then used it to run an actual honey show.
Shows, categories, awards, eligibility rules, label quantities, and the number of secretaries are configurable. The current infrastructure requires reliable internet access. Support for a local network is the next technical challenge for venues with poor connectivity.
Product direction and implementation
I selected React and shadcn/ui and defined the domain rules, workflows, and interaction design. I also set expectations for the component system and tested the software during a live show.
Codex produced essentially all backend engineering and most of the frontend implementation. It also helped select current backend technologies where my knowledge was out of date. I reviewed the work and caught issues such as inconsistent React versions. I then used Codex to standardize the stack and establish CI.
Test it at a live show
The system supported a real show and gave secretaries less information to remember and recopy. Most problems found during the event were implementation bugs. The underlying workflow held up in use.