MatchOps by Match Director HQ is match software for clubs that run precision rifle matches: PRS-style centerfire and rimfire, and Long Gong. A director records the club's steel once and lays out stages at real distances. The matchbook comes out of that work, shooters register from a link, squad tablets score with no signal, and results go out the moment the match is complete.
Free for shooters. Used at live matches, from the first registration to the results email.
When I first started designing a PRS course at my club, I realized how manual all of it was. Knowing what was in inventory and what condition it was in. Building the stages and measuring them so you know how hard they are. Getting that information to competitors. Then everything around it: waivers signed, people registered, squads assigned, and something to score the match, track it, and share it with everyone afterward. Watching how other directors did it, I thought there had to be a better, more automated way. So I built MatchOps.
A match lives in six tools and a clipboard.
Every match starts weeks before the first shot, with a director at a kitchen table working out what plate goes where and whether it's fair at that distance. The rest gets assembled from spreadsheets, documents, a stage-building tool, a scoring product, and whatever the sanctioning body wants submitted. The same number gets typed in three places, the copies drift, and the knowledge of how to run the match lives in one person's head.
- Inventory and its condition tracked from memory
- Target size in MOA worked out by hand, per stage, per distance
- Registration, waivers, and squads on paper or email
- Scores in a separate product, results shared days later
Build the match once. Everything after it comes from that work.
The stage you write is the stage the matchbook prints, the tablets score, and the results add up. Six steps, one record.
Four calls, and the reasoning behind each.
Nontechnical users, no reliable signal, numbers shooters will argue about, and a matchbook some of them have already built dope cards from. Each decision below came from one of those.
A director enters a plate's real size once. MatchOps works out its size in MOA at whatever distance it's placed, which is the number shooters dial and the number they argue about. Because nobody types it, it can't drift between the stage plan and the matchbook.
Stages live in a library and are copied into a match. Edit the library and next month's match picks it up; this month's doesn't, because shooters may already be building dope cards from its matchbook. Convenient for the director, and safe for the people reading it.
Offline scoring means two tablets can score the same shooter differently. No score is silently overwritten. MatchOps keeps both and shows them to a director, who makes the same call they'd make with two paper score sheets, with both sheets in front of them.
The nearest bar of signal is often back at the parking lot, so the tablet works without one. Every score saves on the device immediately, the screen says so, and the sync is something the squad leader can see happen, not something they have to trust.
I decide. Claude plans and reviews. Codex builds.
The other case studies don't have this section because the other products weren't built this way. MatchOps was: every change goes around the same loop, and the loop is the design work I'm proudest of on this project.
I decide what to build. Claude plans the work and writes a brief that names the files, the acceptance criteria, and what not to touch. Codex builds it in its own isolated copy of the code. Claude reviews the diff and the tests, automated checks run, I approve, and the pipeline deploys it.
Each task goes to the cheapest Codex tier that can finish it in one pass, and the brief says why in writing. Mechanical edits go to the small model; anything that edits lines that already exist goes up a tier, because that is exactly where the cheap tiers miss.
Custom Claude skills that encode the project's process for planning, review, and filing issues, so every session starts with the same context and the same rules. Agent instruction files in the repo. GitHub connected through MCP. Issues filed from my phone straight into the backlog.
Who did what, plainly: I set direction, approved every change, and own the result. Claude wrote the briefs and the reviews. Codex wrote most of the code. The design is mine, directed through the same tools.
The agents are fast, confident, and wrong in specific ways.
Knowing where they fail is most of the job. Three failures, and the rule each one left behind.
- Green checks, four visual defects
A change passed every automated check and still shipped four things that looked wrong in a browser. Every brief since ends with a list of what a person has to look at, in both themes, at phone width.
- Tests that could never fail
Agents wrote tests whose assertions no product change could break. The fix is to break the feature on purpose and confirm the test catches it, before the test counts as evidence of anything.
- Three blockers in one night
The first real use of registration found three blocking bugs that no test could see, because no test was a person with a phone at a range. All three were fixed and merged the same night, and real use before a match is now a scheduled step, not a hope.
Same discipline as the usability misses on VSP One File: publish what didn't work, and show what it changed.