Origin
It started with an argument
This project did not begin with technology. It began during league night.
I was playing in the Canadian Poolplayers Association as a league player and team captain. During one match, a scoring dispute came up. Whether because of mistakes, pressure, memory, or alcohol, there was confusion about what had actually happened.
That is the uncomfortable part of paper scoring. When the record is unclear, it becomes one person's word against another person's word.
The Real Problem
Pool scoring was really a trust system.
The score sheet was not just paperwork. It was the shared memory of the match. When that memory became unreliable, fairness became harder to protect.
Community Context
I was solving a problem I personally had
I was not looking at the pool community from the outside. I was inside it. I knew the rhythm of league nights, the paperwork, the pressure, the arguments, the jokes, the uncertainty, and the way one scoring mistake could change the mood of a match.
Pool players show up to play pool. They should not have to spend the night worrying about whether the paperwork is correct.
The Original Vision
The first idea was much bigger than the final tool
At first, I imagined something far more ambitious: a fully automated computer vision system. Cameras would track the table, detect balls, update the score automatically, and remove manual input entirely.
Then reality arrived. Pool halls are messy environments. Nearby tables enter the frame. Players block the camera. Lighting changes. Balls overlap. Striped balls can look solid depending on orientation. A technically exciting solution was starting to drift away from the immediate community problem.
So I pivoted. Instead of chasing the most advanced version, I built the version that could actually help my team.
The MVP
A shared digital record
The minimum useful version was simple: move the scoring process from paper into a digital workflow that players could understand quickly.
It supported CPA-style 8-ball and 9-ball scoring, target scores, current score, match history, ball states, dead-ball logic, and basic tracking. It was not polished as a commercial product. It was a practical tool for real use.
Scoring Screen
The main interface turned the match into a shared state: player scores, target scores, ball states, and match history in one place.
Rules Into Logic
Human ambiguity had to become system behavior
The hardest part was not drawing an interface. It was translating league rules into predictable behavior.
For 8-ball, the tool needed to support innings, winner tracking, handicap support, different skill levels, and races to different win conditions.
For 9-ball, the system had to track points for each ball, count the 9-ball as two points, support dead balls, and handle the moment when the 9-ball is made and the remaining balls automatically become dead.
9-Ball Dead Ball Logic
The trickiest rule work came from deciding how balls should count, stop counting, or become dead under different match states.
UX Lesson
A good product does not need to impress people.
It needs to help them. The most useful version was not the flashiest version. It was the version people could use while still focusing on the match.
Unexpected Tools
The product grew where the community had friction
Once the scoring workflow existed, adjacent problems became visible.
Break tracking let players log table size, game type, balls made on break, dry breaks, and scratches. It created a small practice feedback loop from details that usually disappeared after the match.
Break Stat Tracker
A simple form turned break performance into something players could review instead of vaguely remember.
Equal Opportunity
The random team generator mattered more than it looked
One of the most meaningful features came from my role as team captain: randomly generating teams from a list of available players while respecting skill-level constraints.
That sounds small, but in a league environment it mattered. Team selection can become personal very quickly. People can wonder why someone was picked, why someone sat out, whether the captain had favorites, or whether the same players kept getting opportunities.
The generator turned a socially delicate decision into a clearer system. It gave players a more equal chance to participate while still respecting the practical limits of league rules and skill levels.
That was a major lesson for me: sometimes the most important UX work is not visual polish or technical complexity. Sometimes it is removing the suspicion around a decision.
Validation
The official tool arrived later
Later, the league released its own official digital scoring tool. I cannot claim direct influence, and I do not want to overstate the project. But emotionally, it was complicated.
It felt validating because it confirmed that the problem was real and worth solving. It was exciting to see the same movement toward digital scoring become official. Some visual ideas, including the treatment of dead balls, felt familiar to the direction I had explored.
There was also some disappointment. When you build something from real community friction and later see similar ideas appear elsewhere, it is hard not to wonder what could have happened if the work had been seen or acknowledged. I hold that lightly. The mature takeaway is still the important one: the problem was real.
What I Learned
Small tools can carry real weight
This project taught me that useful software does not have to be large. It has to understand the environment it lives in.
The more specialized the audience, the more important it becomes to understand how they actually think. Pool players have their own language, habits, rules, frustrations, and priorities. You cannot design well for a niche community from assumptions alone.
Usefulness beats novelty
The manual scoring tool was less impressive than computer vision, but more immediately useful.
Rules are UX
Fairness depended on translating league rules into behavior players could trust.
Records reduce conflict
A shared source of truth helped protect the match from memory and disagreement.
Randomness can be fair
The team generator gave players opportunity without making the captain's preference the center of the decision.
Communities have texture
The tool worked because it came from lived experience inside the pool community.
What Comes Next
The future version would still start with fairness
A stronger version could improve visual polish, exportable score records, team lineup generation, match archives, break analytics, and clearer league-specific setup.
A future version could still explore automated match analysis, but the lesson from this project would stay the same: automation is only valuable if it protects the real human need underneath the workflow.
Break Percentage Results
The statistics view showed how a scoring tool could grow into a lightweight feedback system for practice and improvement.
The Messy Kitchen
The clean story is about trust and fairness. The kitchen behind it is rule translation, edge cases, and small features that made league life easier.
Computer Vision Pivot
The pivot was a design decision: prioritize a useful manual workflow over a technically impressive but fragile system.
Team Generation
A small feature with a disproportionately meaningful community impact.
Rule Edge Cases
The hardest design work was making league logic feel predictable in a digital interface.