VOLA

Case study | 8 min read

VOLA: A badminton scoreboard that knows the rules

Every match ended in an argument about the count. So I built a scoreboard that tracks the serve, the court and match point, offline and with no account: researched, designed, built and shipped by one person.

My roleSolo: research, design, build
StackReact Native, TypeScript, Expo
TimelineFifty days to v1.0.0
Shippedv1.0.0, signed APK, Android

FilmVOLA in 52 seconds

Setting up a match, scoring it point by point, and sending the result to the group chat.

The problem
At our court the score lived on a scrap of paper. By deuce nobody knew it, and in doubles nobody was sure who served from which side.
What I did
Designed and shipped VOLA, an Android scoreboard that knows the badminton rules: three scoring systems, doubles rotation, and a minus that undoes the whole point.
The result
v1.0.0, a signed APK installed and used at the court, with 40 of 40 scoring tests passing. A personal project, so the result is use, not revenue.

01The core screens

Start it, score it, share it.

Three screens carry a match from the first tap to the group chat. Rest the pointer on a phone to play it.

Start itQuick Play, singles or doubles, and the official scoring.
Score itOne tap per point. It knows whose serve it is.
Share itThe result, as an image, to the group chat.

02The problem

Every match started with someone swearing they’d remember the score.

Nobody does. Halfway through a rally the count is already an argument, and the scoreboards on the store either want a login or don’t know that the serve changes side on an odd point.

What it was

A score kept in someone’s head

Whoever was counting also had to remember who was serving, and from which court. When a call was disputed, the loudest voice decided it.

→ The argument was the scoreboard.

What it became

One tap per point

The card knows whose serve it is and which service court they’re standing in, and flips both the moment the rally ends.

→ The app works out the rest.

What the store hadEvery scoreboard app I tried was a counter with two buttons
It would happily let you serve from the wrong court, and it forgot the match the moment you closed it.
The rule they all skippedIn doubles the serving pair swaps on their own point, and receivers never swap
So the app has to name the server, not the team, and know which court they stand in.

03Ideation

The problem wasn’t the count. It was the serve.

The arguments on court were never about the count. They were about who serves, and from which side, so that is where the design started.

The single biggest shift

Design against something that already works, and the screens get much simpler.

So the scoring engine came before any screen did. Nothing was drawn until the rules passed, and after that every screen only had to show what the engine already knew.

This ruled in

A scorer that knows service, court side, deuce and the golden point.

This ruled out

A counter that leaves the players to track the serve themselves.

The calls

Three decisions the rules forced, and what each one costs

A counter, or a scorer that knows the rules?

Ruled outA counter with two buttons

Plus and minus for each side. The players keep track of the serve and the court themselves.

ShippedA scorer that knows the serve

It names the server and their court, says who receives, and flips both the moment the rally ends.

WhyThe serve was what got argued about on court, not the count. A counter leaves exactly that part to memory.

What it costsThree scoring systems, deuce, the golden-point caps and doubles rotation, all right before any screen: 40 tests’ worth.

A generic score counter: Team 1 at 14 on a blue half and Team 2 at 11 on a red half, tap to add a point, a minus-one button under each, and Reset — **Ruled out**A counter like the ones on the store: two big halves and a minus. Nothing about who serves, or from where.
**Shipped**The same 14 to 11, with the server and their court named, the receiver, the sets, and the manual fixes.
The counter is drawn for this case study as a generic store app, not a copy of any one.

The shipped scoreboard at the same moment: the sets, Vignesh serving from the right court, Divya receiving, 14 and 11, plus and minus, Swap Serve and Correct Score — **Ruled out**A counter like the ones on the store: two big halves and a minus. Nothing about who serves, or from where.
**Shipped**The same 14 to 11, with the server and their court named, the receiver, the sets, and the manual fixes.
The counter is drawn for this case study as a generic store app, not a copy of any one.

What does the minus button do?

Ruled outTake one point off

A plain decrement, the way every counter does it.

ShippedUndo the whole point

If that side scored last, it restores the snapshot from before the point: the score, the serve and the court positions.

WhyA mis-tap in doubles corrupts more than a number. Taking a point back has to put the server back too.

What it costsA snapshot kept for every point, and a minus that only undoes the last one. Anything else is fixed with Correct Score.

An account and a server, or everything on the phone?

Ruled outSign in and sync

Matches kept on a server and shared between phones.

ShippedNo account, no server, no signal

Everything lives on the phone: local storage, a JSON export, and a result card made on the phone for the share sheet.

WhyCourts have bad reception, and nobody wants to sign up to count to 21.

What it costsA match lives on one phone. There is no sync; the group sees the result as an image.

And three smaller rules: one exit sheet behind the back gesture, the back button and the close icon (Keep Playing, Pause & Resume, End & Save, or Discard when nothing was scored); team A always amber, team B always orange, on the scoreboard, in the stats and on the card; and stats worked out from the match log, never counted up, so naming a Quick Play match days later still gives the right records.

04The solution

The rules live in the app, not in anyone’s head.

One tap per point, and the app works out the rest: the serve, the court, deuce and the golden point.

Prototype · AppA match, start to finish

The app’s own motion, recorded on the phone.

The live scoreboard
One tap per point. It knows whose serve it is and which court they stand in, and flips both when the rally ends.
Nobody has to argue
The BWF rules, simplified and built in, so a disputed call is settled in the app.
One tap to play
Quick Play starts straight away and asks for the names once the match is done.
History that survives
Every match is written to disk: close the app mid-game and it comes back where you left it.
Something worth posting
The victory card, the sets and the stats, sent to the group chat as an image.
Out of the way
No account, no server, no connection needed in a sports hall with no signal.

Up close

The scoreboard, explained

The scoreboard, numbered: the sets, the serve pill naming Vignesh on the right court, Divya receives, the 14 in amber, the minus, and Swap Serve and Correct Score

Every screen, on one canvas

All 9 screens of the app. Pick a group to fly to it, or press the corner button to present it full screen.

Home: a match in progress at 14-11 with Resume, Start Another?, Start Normal Match and Start Pro Match, and recent matches — Home

Set Up Match, step 1 of 3: Quick Play, singles or doubles, Rally 21, Rally 15 or Traditional scoring, and best of 1, 3 or 5 — Match setup

The scoreboard: Vignesh and Karthik 14, Divya and Meera 11, the server and his court named, plus and minus for each side, Swap Serve and Correct Score — Scoreboard

Match summary: the victory card for Vignesh, 15-11 and 15-13, and the set breakdown — Match summary

Match detail reopened from the history: the victory card, Share Achievement and the set breakdown — Match detail

History: the active match with Resume Match, then finished matches with their game scores and winners — History

Players: add a player with a name and a colour, then saved players with their wins, losses and win rate — Players

Badminton rules: official BWF guidelines simplified into seven sections, from the scoring system to scoring systems compared — Rules

Settings: match defaults for scoring, best of and format, then sound effects, vibration, match timer and keep screen on — Settings

05The effort

Fifty days, one person.

No team, no sprint, and no design system to lean on. This is the order the work happened in, from an empty repo to a signed APK.

Step 1
Write the rules as tests
The scoring engine came before any screen: 40 cases for deuce, setting, the 30 cap and doubles rotation.
Step 2
Design for a hand holding a racquet
Thumb-reachable, nothing smaller than a fingertip, scores you can read from the baseline.
Step 3
A prototype at the court
The first APK on 29 May, on a phone, used at the court from the first build.
Step 4
Audit, then sign it
A deep audit and rules pass on 15 July, and the signed release the next day.

40/40Scoring tests passWritten before any screen.
13Custom components, zero UI kitsEverything in v1.0.0 designed from scratch.
50Days to v1.0.0From an empty repo to a signed APK.
1Person, end to endResearch, design, the build and the release.

How it was checked

The rules first, then what breaks on a real court

Check	What could go wrong	What it changed
40 scoring tests	Deuce, the golden-point cap at 30 and 17, traditional side-out, set closure, best-of, undo and manual correction: the rules people argue about.	The engine is plain functions over a match, so every rule is tested without drawing a screen. 40 of 40 pass.
Doubles rotation	The bug every scoreboard ships: who stands in the right service court.	Each team carries that player, and the screen reads it instead of guessing from the score.
A match in a pocket	Timers slow down when the app is in the background.	Time is measured against the clock, and the match is saved on real events only, never once a second.
Bad data on disk	One bad write could stop the app from opening.	On load, broken records are dropped, duplicate live matches merged, and finished matches with no winner repaired.
Rallies not logged	Stats that look complete when half the rallies were skipped.	Insights say “n of m rallies tracked”. Partial data is labelled partial.

06Outcome

Shipped, installed, and used at the court.

A personal project, so the outcome is use, not revenue: the people it was built for stopped keeping score on paper.

v1.0.0 shipped as a signed APK on Android, installed rather than listed.
40 of 40 scoring tests pass, so the app gets the rules right before anyone has to check.
Every match kept: saved on the phone as it happens, and repaired on load if a write ever goes bad.
Offline, with no account, in the sports hall where it gets used.

The call I’d defend: writing the scoring engine before drawing a screen. Designing against something that already worked made every screen simpler.

Looking back

What I would do again, and what I would change

Again

One colour per team, everywhere. Amber and orange meant nobody ever had to work out whose point it was.
Label partial data as partial. “n of m rallies tracked” kept the stats honest.

Differently

Count the use. The app keeps every match, but I never counted how many were scored on it, so the use rests on my word, not a number.
Hand it to a group that isn’t mine. Everyone who used it plays with me and knew the rules; strangers would test the setup and the words.

Up next

Google Pay: Know where the money wentConcept · File each payment in one tap, before the PIN