In defense of over-engineering

I've written before about the Schott Classic - the annual wiffle ball tournament I run that somehow acquired a full software platform. Today I want to defend the part of it that sounds least defensible.

The system has:

• 116 database tables. For wiffle ball.
• Two environments - a production database and a dev database, because you don't test bracket logic against live registrations like some kind of animal.
• Rate limiting and DDoS protection on public endpoints. The threat model here is, at worst, an over-caffeinated captain refreshing the registration page.
• Signup-driven configuration - pools, fields, and bracket structure recalculate automatically as the team count changes, from 16 teams to 40.
• Full financial tracking, budget versus actual, revenue by source.
• A t-shirt quoting pipeline. It ingests vendor quotes and applies them to merch pricing.
• Promo codes. With enforcement. For a backyard tournament.
• Umpire assignment tooling. And a lessons-learned database, because every year we learn things and every year I used to forget them.
• Five years of history - 298 teams across 9 tournaments, backfilled from the spreadsheet era so the records survive.

Every rational software instinct says this is wildly disproportionate. A Google Form and a Venmo QR code would technically run this event.

Here's why I did it anyway, and why I'd tell you to do the same.

Every pain point deserves software now#

For most of software history, "is this worth building?" was a real question, because building was expensive. You triaged. Major pain points got software; minor ones got tolerated forever.

That math has collapsed. With AI-assisted building, the cost of solving a minor pain point has dropped to roughly one evening. So the Schott Classic became my running experiment: what happens if every pain point of running an event - major or minor - gets custom software?

The chased-down waiver gets software. The t-shirt vendor quote buried in email gets software. The "wait, who's umping field 2?" panic gets software. The thing we screwed up in 2023 and re-screwed in 2024 gets a lessons-learned table so 2027-me stops relying on 2023-me's memory.

None of these individually justified a build in the old economics. All of them together transformed the event.

Zero-stakes projects are where you learn new tools#

The second reason is more selfish: the tournament is my lab. Nobody's season ticket depends on my bracket seeding logic, so it's the perfect place to try things - a new ORM, a payment webhook pattern, an AI agent workflow, an auto-configuring scheduler. If it breaks, I fix it at midnight and nobody knows.

Then the patterns that survive graduate to my day job, already battle-tested by forty teams' worth of real users who will absolutely find every edge case, because wiffle ball people are ruthless.

"Over-engineering" a personal project isn't waste. It's the cheapest, lowest-risk R&D program available to anyone who builds. The tournament gets better software than it deserves, and I get a sandbox with real stakes-free users.

The test#

My test for whether something is over-engineered has changed. It used to be "is this more system than the problem needs?" Now it's "did solving it this way cost me more than it taught me?"

By the old test, the Schott Classic platform is indefensible. By the new one, it's the best engineering decision I make every year - 116 tables and all.