AER at Summit Point, 2026. Practice and qualifying on Friday, then two eight-hour races. My timing system sent live standings to the grandstand twice a second for about twenty-four hours of racing, over rural West Virginia internet. I was the only person on ops, and I did it from my couch.
Nothing happened, which was the whole plan.
I’m writing it up anyway because getting to “nothing happened” takes a lot of work, and when it goes well nobody sees any of it.
The software was new that weekend, but the problem was old. I came into this series in the middle of a season and took over a timing system someone else had built. I kept it running for the rest of that season while I built its replacement, so the new one would be ready for the next. GridPulse is that replacement, and Summit Point was its first full weekend. Everything the old system did wrong went into how I designed the new one.
Where I learned to think about failure
My degree is in computer engineering. While I was in school I was also selling an app to fire alarm inspectors, so I was learning hardware in class and learning paying customers at the same time.
The hardware lesson stuck with me. Once a circuit board is built, you can’t patch it. If the design is wrong, it stays wrong. So you work out every limit and every way it can fail before you build it, because there’s no fixing it later.
Software lets you skip that step, and a lot of it gets built that way: ship it, then keep patching until it mostly works. I still build like it’s hardware. Fire inspectors used that app for five years, and once it shipped I almost never had to go back in and fix things. The hard thinking had already happened before it went out.
Everything in the data flow has known limits, known delay, and known ways to fail. Or it isn’t done yet.
The problem
Race timing at a club endurance event is an awkward setup. The real results live on one computer in the timing tower. That computer gets to the internet through a small-town ISP or whatever cell tower is pointed at the track. People are watching live, the race doesn’t stop for me to deploy a fix, and I’m not at the track.
So the job was to get the results off one fragile machine, across a bad connection, to a live crowd, for a whole weekend, with nobody else on the team.
How many people to plan for
I didn’t pick a round number for the load test. I started with registered attendees, added a multiplier for friends and family watching from home, added another for people sharing it, then added a buffer for sudden spikes.
The buffer is the part people usually guess at. I sized it to how long it takes to bring more servers online, since that’s how long a spike has to be absorbed by what’s already running. Once you look at it that way it stops being an argument and becomes math.
The math came out to 10,000 people connected at once. I tested that and it held. The real peak on race weekend was about a hundred.
Who sees the failure
The design choice I care about most is that a problem looks different depending on who’s watching.
Race control needs to know right away. If either end of the connection drops, they get a loud, clear alarm, because they’re running a race and they can do something about it.
Spectators get something calmer. Their screen slows down and a note tells them the data is delayed, not lost. That’s the truth, and an alarm would just worry them over something they can’t fix.
When I was younger I made everything alarm loudly for everyone. It took a lot of years to see that an alarm only helps the person who can act on it.
Race weekend
On Friday I connected remotely to the timing computer in the tower, installed the latest build and logged in. Then I watched the race on my own system like any other fan, with Messenger open in case something looked off.
A few times something did look off, and every time it was the race. A car sat in the pits, or there was a full-course caution. I could tell the difference because I’ve watched this series for years, and no dashboard would have told me that.
The only support questions all weekend came from new users asking what parts of the screen meant. When the pipes hold up, the questions that are left are about the screen itself, so that’s what I’m working on next.
Mid-Ohio
Summit Point was a quiet test. I didn’t tell many people the live timing existed, and about a hundred watched.
At Mid-Ohio, the weekend of October 17th, I shared it properly. A little over 1,500 spectators followed the race on it. That’s fifteen times the Summit Point crowd, and still well inside what the system was tested for. Nothing happened there either.
None of this is exotic. I planned for a real number of people instead of a guess, sized the spike buffer to how long scaling takes, decided who should see which failures before launch, and leaned on everything the old system taught me about where timing breaks.
If your app is about to have its own race weekend, a launch or a big customer or a feature in the press, the Software Audit is this same work done on your system before the day arrives.