A concept prototype for rspba.org — shown here for discussion, built from public 2026 results data
RSPBA crest The Royal Scottish Pipe Band AssociationResults, rebuilt — a proposal
Concept · results.rspba.org

The results, as their own fast site.

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

Today the data is organised for the contest, not for the reader.

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

One dataset, walkable from both directions.

The same results, navigable by band and by contest — and linked, so you can cross between them in a tap.

Browse by band

Open a band and see their whole season at a glance — championships entered, majors won, podiums, form — then the full result behind every placing.

Browse by contest

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.

Linked both ways

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

A static results site, regenerated when results are uploaded.

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.

Step 1
Results uploaded
Exactly as today — the results-entry step stays where it is and how it works.
→
Step 2
Build
A build turns them into a typed (TypeScript) data model, then pre-renders every band and contest view plus compact JSON.
→
Step 3
Publish to CDN
Static files are pushed to a CDN on RSPBA infrastructure — cacheable, cheap, and highly available.
→
Step 4
Instant pages
Readers get pre-built pages with near-zero round-trips; search and filtering run client-side over the small JSON.

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.

The payoff: standings that calculate themselves

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

Results are typed in under pressure — so the build expects holes.

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.

A real example, from this year

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.

Tolerate, don't drop

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.

Every rebuild checks itself

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.

You decide the response a policy to own

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.

The durable fix is upstream — at the draw

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

This is designed to protect what matters, not disrupt it.

Four things had to hold true for this to be worth doing. They shaped the design.

Sponsor income stays first

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.

The data never leaves RSPBA

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.

The rest of the site is untouched

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.

A typed model tidies the data

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

Faster and clearer isn't just nicer — it compounds.

The quickest way to judge it is to use it.

The prototype is fully clickable and built from real 2026 Grade 1 results. A few things worth trying:

Launch the results app →

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.