Building a Charity Site Non-Developers Can Actually Maintain
F.O.G. Canada (Friends of Golf) raises money for community causes through an annual golf tournament. The brief was simple: ship a site the team can edit themselves between cycles. WordPress + Elementor, tuned for non-developers, with sponsorship tiers as drag-and-drop modules.
When a small charity asks for a website, the temptation is to ship the stack you're proudest of. The right move is the opposite, pick the stack the team can keep running after you stop being on call. For Fog of War Canada, that meant WordPress and Elementor, not Next.js.

Why I built it
The previous site was a static brochure that broke every time someone tried to add a new sponsor logo. Registration lived in a Google Form linked from a tiny button, and donation traffic was funneled through a third-party page nobody could brand. The cycle-to-cycle update cost was a volunteer's whole weekend, and the bounce rate on mobile told the rest of the story.
The mission shapes the architecture
F.O.G. Canada (Friends of Golf) is a charity built around an annual golf tournament. The tournament is the year's anchor fundraiser, with sponsorship tiers, registrations, donations, and a sponsor wall that grows from cycle to cycle. The team is volunteers, passionate, but not technical. The site needs to be editable by someone who has never opened a code editor.

What the build prioritized
- Drag-and-drop section templates the team can clone for new tournament cycles.
- A sponsorship-tier component (Title, Eagle, Birdie, etc.) that surfaces logos at the right scale without needing CSS edits.
- Mobile-first layouts because attendees RSVP and donate from the green, not a desktop.
- Lightweight SEO (clean URLs, real meta descriptions, OG cards) so donations don't depend on whoever shared the link.
How I built it
WordPress with Elementor Pro as the page builder, a child theme for the few CSS overrides that needed to live in version control, and ACF for the sponsor-tier data so a logo is one repeater row, not a markup paste. Hosting is on a Canadian provider for latency and donor trust. Caching sits at the edge with auto-purge on save so volunteer edits go live without anyone touching a console.
The sponsor-tier component
Each tier (Title, Eagle, Birdie, Par, In-Kind) is an ACF flexible-content block with a max logo count, a target logo height in rem, and an alt-text field. The template enforces grayscale-on-hover and lazy loading by default. Adding a new Birdie sponsor takes about 20 seconds and zero judgment calls about size.
What was hard
The honest answer is restraint. Every instinct said to rebuild this in Next.js with a headless CMS, ship a Lighthouse 100, and call it a portfolio piece. That would have made the next volunteer's life worse. The real engineering work was deleting plugins, locking Elementor widgets the team should not touch, and writing a one-page editing guide that fits on a phone screen.
The other hard part was the sponsor wall growth curve. The first cycle had 12 logos. By cycle three it was approaching 40, with wildly inconsistent aspect ratios. The fix was a normalization step in the ACF render: every logo gets max-height locked to the tier's target, width auto, and a transparent padding box so the visual weight stays even regardless of what the sponsor sent over.
What I learned
Maintainability is a feature, and for a charity it is the feature. The success metric is not page-speed score, it is whether the board can update the sponsor wall on a Tuesday night without calling me. After three cycles, they can, and that is what made the project actually work.
What's next
- An accessibility pass against WCAG 2.2 AA as the audience and donor base grow.
- A self-serve foursome registration flow with Stripe so team captains don't email a PDF back and forth.
- Year-over-year archive pages so past cycles keep their sponsor recognition without cluttering the current homepage.
The ongoing part
I've been on this project since 2024. Each cycle brings new sponsors, new event photography, accessibility passes as the audience grows, and the kind of small perf tuning that adds up over years. The lesson I keep relearning here: the right project for a charity is rarely the most technically interesting one. It's the one that still works in three years when the volunteer who took over has never met you.

Driving a 3D Map by Voice
Google's photorealistic 3D Maps API meets WebkitSpeechRecognition. Say 'drive me from Mile End to Old Port via the Lachine Canal' and the camera flies. Toggle between driving, walking, cycling, transit.

Quaternions, IMUs, and a Wireless C++ App That Doesn't Lie About Drift
Reading IMU data over wireless and turning it into a stable 3D rotation in OpenGL is mostly an exercise in fighting drift honestly. The hardware lies; the math tells you when.