Welcome to the tour!
Put two finished hackathon projects on a stage and you can compare what they built. You usually can’t see the decision that rescued one of them at 2 a.m., or tell whether the other would survive its first busy afternoon. The demo has edited out most of the engineering.
We want AHP Tour to make those decisions watchable while they still have consequences. The idea is a tennis match played through two running systems, with an opponent choosing the next bit of pressure and an audience able to follow what happens to both.
Good for builders, harder for spectators
Hackathons give people a deadline, a reason to finish something, and other builders to learn from. Their usual ending makes sense for that job. Major League Hacking recommends science-fair judging: teams demonstrate their projects to visiting judges, with an optional finalist presentation at the closing ceremony. It’s a practical way to give each team time to explain its work.
AI-assisted building fits into that structure too. In the 2025 World’s Largest Hackathon presented by Bolt, entrants built applications primarily with Bolt and submitted a working project link and a demo video under three minutes. The rules allowed judges to evaluate the supplied materials without testing the app. That puts a lot of weight on what a team can show in a short demo.
For an outside viewer, the awkward part is the gap between starting and presenting. Different teams are solving different problems, and the significance of a change often depends on hours of context. Streaming everyone’s editor doesn’t fix that. You can watch someone type for twenty minutes and still have no idea whether they’re winning.
Give both players a shop
The AHP tennis format gives two engineers separate copies of the same healthy online shop. Same starting code, data, resources, and rules. Each player owns the whole purchase path, from the catalogue to payment and the final order, and can change their code and infrastructure while the match runs. The customers and money belong to the game; the engineering tools are real.
A serve is a production condition chosen from a published, bounded set: more checkout traffic, a slower payment provider, a cold cache, or a lost instance. The referee applies it to both shops at once. You have to survive your own serve. Neither player can get into the other’s system, but the audience gets to see both responses.
That shared pressure gives the viewer a comparison they can follow. One player might buy capacity while the other fixes work that shouldn’t be happening in the first place. This illustration puts those choices in front of the same audience:
A rally you could follow
Take the example on the About page. A serves a 1.8× demand surge, weighted toward checkout. Both shops get busier. B’s database connections fill up and requests begin waiting. A has chosen the pressure, but A’s own customers are arriving faster too.
B finds that repeated payment attempts are making the backlog worse. They limit the retries, test the change, and deploy it to a small share of traffic first. If the shop holds the required customer service target for the court’s ten-second stability window, B has made a return and gains the initiative to choose the next condition.
B then serves a payment-provider slowdown of 650ms. A’s retries now multiply the load. The audience can follow the consequence of B’s earlier fix, and A has a decision to make while shoppers keep approaching their purchase deadlines. More servers might help, but they cost money and won’t necessarily fix a slow dependency.
A commentator has something specific to explain here: which requests are piling up, what each player thinks is wrong, and whether the response is working. Viewers who know databases can inspect the connection pool. Everyone else can follow a shopper trying to finish checkout before time runs out.
Make the score mean something
Under the proposed rules, a correct purchase completed within twenty seconds earns $5 in game dollars. Infrastructure spending comes out of those earnings. If both shops recover within the published window and stay within budget, the higher net result at the end of the rally wins the point.
Buying more capacity can therefore be the right move and still lose to a cheaper fix. Suppose a rally ends like this, with both players meeting those conditions:
| Result | Player A | Player B |
|---|---|---|
| Correct purchases within 20 seconds | 100 | 90 |
| Purchase earnings | $500 | $450 |
| Infrastructure cost | $160 | $80 |
| Net result | $340 | $370 · Point |
A served more customers, but spent an extra $80 to earn an extra $50. B wins the point. The audience can check that arithmetic without accepting a judge’s opinion about whose architecture looked more impressive.
Correctness still sets the limits. Missing the recovery window or breaching the budget loses the point; losing a confirmed order or charging twice forfeits the game. A fast checkout that quietly loses the purchase doesn’t get rewarded.
The broadcast has work to do
The proposed broadcast pairs each player’s terminal, editor, and telemetry with customer outcomes, a clock, and the score. It needs to show who chose the current condition and who has initiative. A wall of tiny dashboards would be miserable television. The production has to keep the consequence of a decision visible, then let interested viewers go deeper.
The format is still a proposal. Fair conditions, readable broadcasts, and scoring that rewards good engineering all need to hold up in play. We haven’t established that people will want to watch a full match. The useful test is whether a viewer can arrive halfway through a rally, understand what’s at stake, and care about the next deployment.
Hackathons already give builders a reason to make something. AHP Tour could give an audience a reason to stay while the engineering happens. If spectators can see why B’s fix held, why A’s extra capacity fell short, and what the next serve might expose, there’s a match to follow. That’s the tour we want to build. Welcome.