The score needs somewhere to live.
Recording a final result solves one moment. A recurring competition also needs that result to stay findable and contribute to a running table and player record.
Independent product · Android + web · 2026
ScoreKeeper.
Designing an Android-first football companion where one final score keeps the competition current.
One final score. An entire competition kept current.
I designed and built ScoreKeeper around a canonical match record: a quick final score that updates recent results, standings, player profiles, groups and rivalry context. The case study focuses on keeping context clear across the shared system.
- Surface
- Android app + responsive web
- Stage
- Working product
- Timeline
- 2026
- My role
- Product design + implementation
The match ends. The competition continues.
Rank tells only part of the story.
A table shows position, but repeat opponents and recent form give the competition personality. The design challenge was to surface that context without making result entry more demanding.
A fair comparison needs clear boundaries.
Solo matches, team matches and different groups are distinct contexts. I needed the entry flow and the table to make those differences visible, so a precise number would also have a clear meaning.
Making the thinking visible.
Make one save do the bookkeeping.
I kept entry focused on group, players, match mode and final score. The saved result becomes the basis for history and the surrounding statistics.
Players should not need to maintain a leaderboard separately. The same result can update the competition and each player’s context.
Record the final scoreOne shared match recordHistory + standings + profiles
The tradeoff. A small input creates a larger engineering responsibility: updates and corrections must stay consistent across dependent views.
Keep solo, team and group contexts visible.
I made 1v1 and 2v2 explicit and kept player and team standings separate, with group scope carried through the flow.
A team victory and a solo victory describe different things. Clear scope makes the table easier to interpret and prevents misleading comparisons.
Choose group + modeRecord the right participantsCompare within that context
The tradeoff. Extra modes add controls. I kept them close to the action they change, so people can see which competition they are recording.
Add personality without inventing the match.
I used final-score calculations for form and rivalry context. Tone adds personality while the underlying evidence stays the same.
The product records results, not possession or chances. Its interpretation should help friends understand a rivalry without implying data it never collected.
Recorded resultsForm + head-to-headA grounded rivalry story
The tradeoff. This limits tactical depth. I would first test which insights people understand and revisit before asking them to record more data.
One final score. An entire competition kept current.
Current local product screens from the built-in guest demo, shown in an Android-style frame.
Keep the input lightweight.
Choose the context, players and final score. ScoreKeeper asks for only the information people can reliably record after every match.
See where the result puts you.
Player and team tables keep different kinds of competition separate. Rank becomes a reason to look at the next matchup.
Give the numbers a person.
The player directory connects the table to individual records. Profiles and comparisons let people explore the competitors behind the score.
Make the rivalry readable.
Form and head-to-head context turn repeated results into a story. The calculations use final scores, keeping the interpretation within what was recorded.
Let the next result move the story.
A rematch adds new evidence, updates the rivalry and changes the next recommendation. The value compounds when the group keeps recording.
What the work taught me.
What exists
A working React product with an Android Capacitor project, guest mode, shared results, standings, profiles, groups and Insights. Native integrations include notifications, haptics and home widgets.
What I learned
A scorekeeping app is also a system of shared expectations. Who is playing, which table counts and what happens to a shared result are interaction-design decisions as much as data decisions.
What I would test next
Follow a small group across several match sessions. Check time to save, whether they can explain the ranking, and which view brings them back. Also test reconnect and correction flows on a physical Android device.
The guest demo makes the core interaction reviewable. This case study does not establish public Play availability, download counts or retention results.