RU Foundation
A nonprofit that has supported Radford University since 1973. We redesigned and built their WordPress site around the three audiences it has to serve, then years later rebuilt it as a static-first site when WordPress stopped earning its keep.
Visit rufound.orgRadford University Foundation, Inc.
WordPress, rebuilt on Astro + Vercel
Design, development, content migration, accessibility
The challenge
The Foundation serves several very different audiences at once: donors ready to give, students looking for scholarships, and anyone who needs the public record, from Form 990s to governance policies. The site they had made all three groups dig. Nonprofit transparency only works when the documents are actually findable.
The redesign: give, apply, verify
The first engagement was a full redesign and WordPress build organized around the three jobs the site has to do. Giving paths (online, mail, stock, planned gifts, matching) sit one click from the homepage. Scholarships get their own clear track. Audits, 990s, policies, and annual reports live in a single public-documents hub.
That information architecture is the part of the project that has aged best. It still shapes the site today, and it is what let the Foundation's team run news, board listings, documents, and the annual report cycle themselves without a developer in the loop.
Why we rebuilt it
The WordPress build did its job for years. What changed was the cost of keeping it. A page builder had grown between the team and their own content, so routine edits meant fighting a layout tool instead of writing. The plugin stack that made the original build fast to ship had turned into a standing update and security obligation for an organization with no full-time web staff. And a site that is mostly stable documents and news was paying to assemble every page on demand, for every visitor.
The content model was sound, the delivery model was not. So we kept the first and replaced the second.
The move to Astro
The site is now 40 pages, every one rendered to finished HTML at build time and served straight from the edge. Nothing is assembled per visitor, there is no database call on the critical path, and the attack surface of a plugin ecosystem is simply gone. Content lives in typed collections with schemas that fail the build if a required field goes missing, which catches a bad edit before it reaches the site rather than after.
The events page shows what static buys you. It gathers roughly 284 live events from the university, athletics, and alumni calendars alongside the Foundation's own, assembles them at build time, and still shows something useful if one of those feeds is down. Filters live in the URL, so a filtered view is a link you can send to someone.
Interactive pieces, the carousel, the accordions, the document filters, the calendar, are small scripts scoped to the components that need them rather than a front-end framework loaded on every page. The production build ships no separate JavaScript bundle files at all: everything is small enough to inline, so nothing blocks the page from rendering.
Nothing left behind in the move
A migration is only worth as much as the content that survives it. We wrote an importer that pulls the WordPress site into the new one: 30 news posts, 27 PDFs, and 30 images, with page-builder markup stripped back to clean prose, leftover placeholder text detected and dropped, and a long-broken outbound link repaired on the way through.
It can be run again safely. Hand-edited work, like rewritten document descriptions and re-cropped cover images, is protected rather than overwritten on the next import. Alongside it, 42 old URLs redirect to their new homes as real 301s, generated from a single list instead of maintained by hand, so search rankings and years of inbound links carry over.
Accessibility and hardening
The contact form and newsletter signup are the only two routes that still run on a server, because they are the only two that need to hold secrets a browser can never see. Contact submissions route to specific staff by ID, checked against the staff directory so that someone leaving surfaces as a loud error instead of quietly shortening the recipient list. The sender's address goes in Reply-To rather than From, so replies work without tripping DMARC, and nothing about the message body is ever logged. Newsletter signups answer a repeat address exactly the way they answer a new one, so the footer form cannot be used to test who is on the list. Both sit behind Cloudflare Turnstile, checked on the server rather than taken on faith from the browser, scoped per form so a token issued on one cannot be reused on the other, and set to fail closed if anything goes wrong.
On the front end, the build uses a full landmark structure, keyboard-operable tabs and carousels with off-screen slides made inert, live-region announcements when filtered content changes, and a documented responsive system in place of the desktop-only layout it started from. Content security, HSTS, referrer, and permissions policies are applied across the whole site. Every build also runs a link and asset checker we wrote for the project, so a broken internal link or a missing PDF stops the deploy instead of shipping.
