Active build, in production
Rebuilding a 20-Year-Old Sports Platform Without Losing Its Rules
A sanctioning body running memberships, tournaments, payments, and a season-long classification engine on a FrontPage-era ASP site. We rebuilt it ground-up: 445 business rules recovered from 1,114 legacy files first, then a modern platform now at 770 commits, 166 ordered database migrations, and roughly 5,800 automated tests.
- Client
- A youth fastpitch softball sanctioning body
- Industry
- Youth sports sanctioning and tournament operations
- Location
- United States, active across roughly 18 states
The short version
- The organization sanctions youth fastpitch tournaments across roughly 18 states: memberships, event entry, payments, umpire compliance, and a points engine that auto-classifies teams over a season.
- All of it ran on a classic-ASP site graded D+ in our audit: no mobile viewport, fixed-width tables, no per-page titles or schema, and the business rules existing nowhere but the code.
- Before writing the new platform we reverse-engineered the old one: 445 business rules recovered from 1,114 legacy files, so the rebuild had a spec instead of a guess.
- The rebuild is live and under continuous delivery: 770 commits since June 2026, 166 ordered migrations, about 5,800 automated tests, with the owner running acceptance testing in parallel.
- Money paths get the strictest treatment: fee changes ship with concurrency proofs and production verification against row-level snapshots, not assumptions.
What was actually wrong
Twenty years of operations were encoded in a website nobody could safely change. The classification rules, fee structures, eligibility windows, and tournament formats lived only in the legacy code and in the owner's head.
The site predated smartphones and never caught up: no mobile layout at all, on a platform whose audience is parents standing at a ballfield.
Every rewrite of a system like this faces the same trap: the new platform quietly drops rules the old one enforced, and nobody notices until a season is mis-scored. The job was not to build a new site. It was to move two decades of rules without dropping any.
What we built
The rules, recovered before anything else
A reverse-engineering pass over 1,114 legacy files recovered 445 discrete business rules: season and age eligibility, the points and auto-classification engine, double-elimination and pool formats, event geography protection, fees, background-check compliance. That document became the binding spec, so the rebuild answers to the old system's actual behavior rather than to memory.
The platform
A modern web application: role-based accounts for members, umpires, players, and college coaches; event entry and payments; the season-long points and classification engine; rosters and recruiting visibility; per-event pages. Built mobile-first, because the audience is at a ballfield, not a desk.
A delivery process built for money and standings
Every schema change is an ordered, numbered migration applied to production in sequence, 166 so far. Changes touching fees or standings ship with automated tests plus direct production verification: row counts snapshotted before and after, boundary cases reproduced exactly, and concurrency behavior proven with multi-session database probes rather than reasoned about.
Owner-driven acceptance testing
The owner runs the real workflows against each build and files findings; those findings are triaged into build items, decisions, and schema changes. Build and acceptance run in parallel rather than as phases, which is why defects surface in days rather than at handoff.
What the numbers say
Every figure below carries the source it came from and the date it was pulled. Where we do not have a number, the row says so instead of estimating one.
| Measure | Result | Source |
|---|---|---|
| Business rules recovered from the legacy system before the rebuild | 445, from 1,114 legacy files | Reverse-engineering pass, repo analysis records, July 2026 |
| Commits on the rebuild | 770 between 3 June and 20 August 2026 | Git history, counted 2026-08-20 |
| Ordered database migrations applied to production | 166 | Migrations directory, counted 2026-08-20 |
| Automated test cases | Roughly 5,800 across 358 test files | Repo test suite, counted 2026-08-20 |
| Legacy site mobile experience, before | Graded F in audit: no viewport tag, fixed 1000px table layout | Site audit, 2026-06-28 |
| Revenue impact figures | None quoted. The rebuild is mid-engagement and the season is in progress, so any revenue claim now would be a projection. This row will carry measured numbers when a full cycle has run. | Stated rather than estimated, on purpose |
What we did not do, on purpose
The decisions not to build something are usually the ones worth reading.
- We did not start by writing code. We started by recovering the rules, because a rewrite that guesses at twenty years of edge cases ships a season mis-scored.
- We did not rebuild live game scoring. Incumbent tools already do it well, and rebuilding it would have burned months on the one feature the market had already solved.
- We did not big-bang cut over. The legacy site keeps running while the rebuild proves itself workflow by workflow under real acceptance testing.
- We did not treat schema changes casually. A standings engine and a payments path are exactly the places where a silent partial failure costs real money and real seasons, so every change there carries a proof, not a promise.
What we took from it
- Reverse-engineer first, build second. The 445-rule recovery is what made the rebuild a translation instead of a guess, and it surfaced rules the owner had forgotten were enforced.
- Owner-run acceptance testing in parallel with the build beats a phase-gate handoff. Findings arrive while the context is fresh, and the owner sees progress weekly instead of at the end.
- On money paths, verify against production state, not against the plan. Snapshot the rows before, check them after, and prove concurrency behavior with real competing sessions.
- Long-standing and family-adjacent clients get the same discipline as strangers: written scope, ordered migrations, and evidence. Familiarity is not a reason to skip the gate; it is a reason the gate protects the relationship.
Timeline
Legacy audit June 2026. Rules recovery July 2026. Rebuild under continuous delivery since June 2026, in production with acceptance testing running in parallel. Ongoing.
How it was priced
Custom build, scope-quoted, ongoing. We do not publish what an individual client pays, but every rate we charge is on the pricing page.
Questions about this engagement
Why rebuild instead of buying an off-the-shelf sports platform?+
Because this organization is a sanctioning body with its own classification engine, points system, and compliance rules. Off-the-shelf tournament tools do not encode those, and handing its rules to a generic platform is exactly what makes sanctioning bodies interchangeable. The rules are the asset; the rebuild preserves them.
What does recovering 445 business rules actually mean?+
We read the legacy system, 1,114 files of it, and wrote down every rule it enforced: eligibility windows, fee logic, classification thresholds, bracket formats, geographic protections. Each became a numbered, testable statement. The rebuild is checked against that list, which is how a rewrite avoids silently dropping behavior nobody remembered was there.
How do you change a live payments or standings system safely?+
Ordered migrations, applied in sequence, never edited after the fact. Anything touching money or standings additionally gets automated tests, a production verification against before-and-after row snapshots, and, where concurrent access matters, multi-session database probes that prove the locking behavior instead of assuming it.
Why are there no revenue numbers on this page?+
Because the engagement is mid-flight and the season is in progress. A revenue claim today would be a projection dressed as a result, and every number on this site carries its source. When a full cycle has run, this page gets the measured figures.
Why is the organization not named?+
The same rule as every study here: we name a client only with written approval on file. It also matters that readers judge this work on the evidence, which is countable in the repository, rather than on who the client is.
What did this cost?+
We do not publish what individual clients pay. Every rate we charge is on our pricing page; this is a scope-quoted custom build with ongoing delivery.
Want to know what is actually wrong with yours?
That is what the free audit is for. A written, fixed-scope diagnostic with a quick turnaround, ranked by impact against effort, yours to keep. You can also read the other case studies or see how we work with Nashville organizations.
Request Your Free Audit