How do you build the best hockey umpire app for the person holding the whistle?

The best app starts with the match, not the feature list

A player scores. You are moving, watching the players and preparing for the restart. You need to record the goal without losing the match. That is a better starting point for an umpire app than a list of attractive screens.

For HockeyUmpire, ‘best’ is the design ambition: fit the work of the umpire as closely as possible. It is not a claim that we have objectively beaten every competing app. The questions are practical. Can I see the clock at a glance? Can I correct a mistaken input? What happens when the Watch locks, the devices lose contact or the match ends?

HockeyUmpire is an iPhone and Apple Watch app for field hockey match control. Its public product pages describe time, score, cards and penalty-corner controls, with additional review and analysis features. Ludo Raedts, its maker, is an active field hockey umpire. That first-hand context supplies the needs; AI helps turn them into a product.

HockeyUmpire is our own project. This case explains the working method behind it, rather than offering an independent review or a model leaderboard.

• Explore HockeyUmpire and its match workflow ↗
• View HockeyUmpire on the iOS App Store ↗

Do not ask AI to build the whole app. Ask it to understand one moment.

‘Build the best hockey app’ gives an agent almost no basis for choosing between competing ideas. Describe the person, the situation and the action that matters instead. A score correction while play is paused is a different interaction from adding a goal while moving.

In this project, ChatGPT helped with early product thinking; Codex and Claude Code became implementation and review partners. The useful distinction is the job each assistant receives, not a permanent ranking of models. The human owns the product priorities, the applicable rules and the decision to release.

The first output should be questions and observable behaviour, not a large code change. If the agent cannot describe what the umpire should see and do, it is too early to implement the feature.

Turn ‘make it easier’ into a testable interaction

AI can make a screen cleaner without making the task easier. Feedback needs a target: which information must be visible, which action should be quick, and which accidental action must be recoverable?

A useful review connects a screenshot to a match scenario. ‘The team name is cut off on this Watch size’ is actionable. ‘It feels wrong’ needs one more question: what were you trying to do, and what got in the way?

The following are example acceptance criteria to agree before coding, not measurements of the current app. Choose them for the specific feature rather than treating them as universal interface rules.

The iteration loop: brief, build, observe, correct

The work advances through small loops: agree on one behaviour, inspect the existing implementation, build a limited change, test it and feed the observations back. Each round should answer a question. Did the new arrangement make the correction understandable? Did the change preserve the clock? What still fails?

Do not restart from a grand prompt after every disappointment. Keep the agreed constraints, identify the part that failed and ask for a targeted revision. Also say what already works and must stay unchanged. Otherwise the next attempt can undo the useful part of the previous one.

Keep a known-good checkpoint. A small patch is easier to review and recover from than a broad refactor presented as one improvement. The agent should explain the expected benefit and the functions at risk before it changes them.

A useful bug report shows what works as well as what fails

During development, a Watch freeze gave us a useful contrast. A match started directly on the Watch worked; a match sent from the iPhone failed. That comparison was more useful than simply reporting ‘the Watch freezes’. It pointed the investigation towards the differences between the two starting paths.

The lesson is not that the first hypothesis was necessarily right. A return to a known-good version and a restart were part of recovery, so the exact cause was not established. A problem disappearing is not proof that the most recent patch fixed it.

Give the agent the reproduction steps, expected result, observed result, device and OS, and the last working build. Ask for a discriminating test before accepting another speculative patch. Do not make restarting or reinstalling the first experiment if doing so would lose the only logs or unsaved data.

Test the clock against reality, not only against your code

A match clock is a good example of why ‘the tests passed’ is not the end of the conversation. During development, idealised whole-second test ticks failed to expose a clock regression. Real devices sleep, resume and deliver callbacks irregularly.

Ask what the test assumes about reality. Then make the scenarios less comfortable: irregular timing, a locked screen, interrupted sessions and repeated actions. The test should check the intended behaviour, not merely repeat the implementation's own assumptions.

Use more than one kind of check. Automated tests cover repeatable logic; simulator checks help inspect screens; real-device checks cover the actual experience of timing, haptics and paired devices. A screenshot cannot tell you whether a wrist signal was perceptible while running.

A second agent reviews the change, not the first agent's confidence

Our working principle is simple: the agent that did not build the change reviews it. Independence here means a separate review task against the code and requirements, not a guarantee that a second AI cannot make the same mistake.

A useful example concerned a workout with heart-rate data but no GPS route. The review focused on the order of finishing and saving, including what happens when route saving takes longer than expected. The important question was not only ‘does the happy path save?’ but ‘can a timeout or a new session leave the state inconsistent?’

Give the reviewer the diff, the accepted behaviour, the builder's briefing and test evidence. Ask it to distinguish a defect it can demonstrate from an unanswered question. The human then decides which device scenarios are necessary and whether the change is ready.

Build a test card the umpire can actually follow

A manual test should be specific enough that another person can repeat it. Record the build, devices, prerequisites, steps, expected outcome, actual outcome and evidence. Leave unperformed scenarios marked untested rather than treating a green unit-test result as their substitute.

For a change involving match storage, a useful proposed scenario is: finish match A, confirm it is visible, start match B, then verify that A remains unchanged. For a clock change, define the pause and lock sequence and compare against a separate time reference. For a route change, inspect both the saved workout and route after a real permitted outdoor test.

These are reusable examples of test cards, not reproduced sign-off entries. Run experimental builds in a controlled session before relying on them in a live competitive match. Keep health information and identifying match data out of shared logs.

Translate the umpire's task, not just the English words

HockeyUmpire is offered in seven languages. Localisation is another iteration problem: a short Watch label, a setup instruction and a full sentence can need different wording even when the English source uses the same word.

A shared ‘Start’ key exposed this problem: its different contexts needed to be separated. The general lesson is useful beyond hockey: give the translator the screen, action and space constraints, and ask it to flag reused keys that cannot carry one meaning in every context.

Work one language at a time. Use a project glossary and relevant federation terminology, request a proposal before editing, preserve placeholders and review the result in the interface. A character limit alone does not prove text fits: actual type, screen size and layout matter. Language quality and on-device fit are separate review tasks.

Let the human challenge the explanation

An AI explanation is a hypothesis to investigate, not a reason to disregard what happened on the pitch. If a route shows a position where the umpire did not go, the first useful response is to preserve that observation and examine data sources, not persuade the umpire that the picture must be right.

The same applies to the rules. Supply the relevant federation document, competition context and effective date before implementing a shoot-out flow. Turn the rule into worked scenarios and have a knowledgeable human check the result; do not let an agent invent sporting rules from memory.

Product judgement stays human too. A less ambitious feature that preserves match control can be the right choice over an impressive addition that makes the core unreliable. AI can propose options and explain trade-offs. It cannot approve its own evidence on behalf of the umpire.

• Use the coding-agent briefing and review guide

Before the next build, ask these five questions

The useful skill is not finding one perfect prompt. It is learning to direct an evolving conversation: describe the task, expose assumptions, inspect the result, test the behaviour and use what you observed to choose the next small change.

That is the method readers can take from HockeyUmpire into their own projects. Start with one person's real work. Make success observable. Keep the feedback loop short. Test where the product will actually be used.

• Which exact user moment are we improving, and what should remain unchanged?
• What evidence or rules does the agent need instead of guessing?
• What is the smallest change we can inspect and safely recover from?
• Which test could demonstrate that our assumption or implementation is wrong?
• What did the human actually observe, and what does that mean for the next iteration?