A working prototype that reorganises contest results around the questions people actually ask — how has this band done this year, and who won this contest — on a site that loads instantly, without touching the sponsor income, the data, or the rest of rspba.org.
Built from real 2026 Grade 1 data scraped from the current site. Everything below is a proposal; the prototype is live and clickable.
The gap
The results are held inside the main site, one event at a time. That answers “who competed at Dumbarton?” perfectly well — but not “what kind of season has my band had?”, which is the question a player, a follower, or a prospective sponsor actually starts with. Reaching it today means opening event after event and holding the picture in your head.
The experience around it doesn't help: pages are heavy and slow, and on a phone the first screen is spent on an oversized crest and a centred menu button before a single result appears. The information is all there — it just isn't organised, linked, or fast enough for the way people read it.
The prototype
The same results, navigable by band and by contest — and linked, so you can cross between them in a tap.
Open a band and see their whole season at a glance — championships entered, majors won, podiums, form — then the full result behind every placing.
Open a contest and see the whole field as one sheet — piping, drumming and ensemble side by side, sortable by discipline, with the tie-breaks shown.
Tap a band inside a contest to jump to their season; tap a contest inside a season to jump to its field. Search and season/grade filters keep it usable at full scale.
Architecture
No new database to run, no per-request rendering. Results are turned into a typed dataset and pre-built into static pages and small JSON blobs, served from a CDN.
Where it lives. It runs standalone at results.rspba.org, behind the same header, navigation, footer and sponsor banners, so it reads as part of rspba.org while being independent of the WordPress runtime. A static-site generator such as Astro with a typed data model is a natural fit; the key point is the shape — build once on upload, serve static — not the specific tool.
Because every result flows through one typed model, the Champion of Champions league tables can be derived straight from the results — recomputed automatically the instant a major's results publish, rather than tallied and maintained separately. They stay arithmetically correct and can never drift out of step with the results they're built from, so season-long standings become a by-product of publishing rather than a job of their own.
The data is entered by hand
Contest results are entered manually, often at the field on the day. Band numbers get skipped, a grade is labelled two ways, a row is entered twice. That is normal, not a failing — but a results site has to decide what to do when it happens.
At the 2026 World Championships, the Grade 2 qualifying bands were entered without band numbers — not a mistake, simply because there was no easy way to add them at the time. Taken literally, that makes a whole qualifier look empty. On this site those bands still appear in full; only the link through to each band's own page waits on the number being added later.
A missing number, a stray spelling, a duplicated row — the build works around it and still shows the result. A gap in the data never silently becomes a gap on the page.
An automatic audit accounts for every result in the upload against every result shown. Anything it can't place is listed with the reason — so a result can never quietly disappear between one build and the next.
When the check flags a hole, the Association chooses what happens: hold the update until it's fixed at source, publish with the gap clearly marked and flagged for correction, or accept it as-is. Our recommendation is the middle path — keep results flowing, show nothing false, and let the report drive the fixes.
Most of these holes exist because identity is added late, by hand. Capture each band's number once, at the draw, and it can travel with the band through every artifact used on the day — the draw and running order, the judges' sheets, the qualifiers and final, and results compilation — so the results arrive already clean, no re-keying and nothing to reconcile. The site here is the visible end of that chain; the same typed model that powers it is the natural place to begin anchoring identity from the entry in, so the gaps stop being created in the first place. Adopting the results view first proves the model with no disruption; extending it back through the day's paperwork is where the data-quality problem is actually solved.
Built around the real constraints
Four things had to hold true for this to be worth doing. They shaped the design.
There's no ad network in play — the banners are served directly, so nothing depends on a third party and nothing is lost in a move to static. The prototype runs those same banners in the same place they run now: centred under the menu on desktop, and on the mobile first screen. The paid placement isn't demoted — and a faster, more-used results site is better inventory: more visits, better viewability, and room to rotate more sponsors through the slot. Switching a banner is now reflow-free, so it never disturbs the reader.
Everything is generated from your own results uploads and published to your own subdomain and CDN. No member or contest data is handed to a third-party host or platform. Ownership and control stay entirely with the Association — the build is just a step that runs against data you already hold.
This is additive. News, calendar, education and shop stay exactly as they are in WordPress. Only the results section becomes a fast static site behind the shared chrome — so there's no risky “replatform everything” project, and it can be adopted (or paused) on its own.
Building this surfaced real inconsistencies in the public results — the same grade labelled several ways, a band's name spelled two ways across events, and the medley/MSR format for some contests recorded only inside a news-post image. A typed model makes these explicit and catchable at build time, quietly improving data quality as a by-product.
What it unlocks
The prototype is fully clickable and built from real 2026 Grade 1 results. A few things worth trying:
The prototype carries Grade 1 and the 2026 majors; other grades and seasons show the empty states you'd wire up next. Keep this page and the prototype file in the same folder so the button opens it.