PAUG.net:
Community Platform
The Problem
I co-founded the Pittsburgh Ableton User Group with Paul Miller and Steve Knots about a decade ago. For most of that time, we used Facebook and Instagram to announce events, share mixes, and keep the community connected. That worked until it didn't.
The decline was gradual and then sudden. Facebook's algorithm changes meant that even people who followed the group page were not seeing our posts. Instagram reach dropped in the same direction. Platform instability, outages, policy shifts, and the general feeling that Meta was no longer building for communities like ours made it clear that we were renting space on someone else's infrastructure. Members were missing events. New people couldn't find us reliably. There was no central, permanent place that represented what PAUG actually is.
This is not a unique problem. Small creative communities everywhere ran into the same wall. The difference is that most of them don't have a web developer as a co-founder.
The Design Question
What does a community hub look like when it actually belongs to the community?
The goal was not to replicate social media. We did not need a feed, we did not need likes, and we did not need an algorithm deciding who sees what. We needed a place where anyone could find PAUG, see upcoming events, read about who we are, and optionally get on a mailing list. Simple on the surface, but the design decisions underneath that simplicity mattered.
What I Built
PAUG.net is a static site built with Next.js, deployed on GitHub Pages, and configured with a custom domain. The site includes an events page, a blog, an about page with bios and photos of all three founders, and infrastructure for a mailing list signup via Mailchimp.
Aesthetic as Identity
The visual direction was intentional. PAUG is an electronic music community rooted in production culture, not a corporate meetup group. The design reflects that: dark backgrounds, neon accent colors, a scanline overlay that references CRT monitors and analog gear, and a glitch-inflected visual language. The typography pairs Space Mono (for headers and labels) with Inter (for body text), giving the site a technical feel without sacrificing readability.
The aesthetic is closer to brutalist or punk design than anything you would find in a SaaS template. That was the right call for this audience. PAUG members are producers, DJs, and sound designers. The site needed to feel like it belonged to them, not like a startup landing page someone forgot to customize.
Content Management for Non-Developers
A site that only the developer can update is a site that stops getting updated. One of the three founders, Steve, handles most of the event coordination. He needed a way to post events and blog entries without touching code, opening a terminal, or learning Git. Decap CMS solves this. It provides a browser-based editing interface that commits directly to the GitHub repo, which triggers a rebuild and deploy. Steve can log in, write a post, and publish it. The pipeline handles the rest.
This was a design decision as much as a technical one. The CMS had to be simple enough that the least technical founder could use it confidently, without training beyond a five-minute walkthrough.
Mobile-First Navigation
Most of PAUG's audience checks event details on their phones, often right before heading out. The navigation is a responsive hamburger menu that works cleanly on mobile without hiding important content behind too many taps. Desktop gets the full nav bar. The layout adapts but the information hierarchy stays consistent across breakpoints.
Infrastructure
DNS is configured and pointing to GitHub Pages. SSL is provisioned automatically. The deployment pipeline is GitHub Actions triggered by pushes to main. There is no server to maintain, no hosting bill, and no database. For a community group that runs on volunteer effort, that operational simplicity matters. The less infrastructure overhead, the more likely the site stays alive.
Design Decisions That Mattered
No algorithm, no feed
The whole point of leaving social media was to stop being subject to algorithmic distribution. PAUG.net is a flat site. Everything is visible, everything is findable. If there is an event posted, anyone who visits the events page will see it. That is the feature.
Founder bios as trust signal
The about page includes photos and bios for all three founders. For a community group, knowing who runs things matters. It is a trust signal, especially for people discovering PAUG for the first time. Real names, real faces, real context about why we started the group and what it is for.
Mailing list over social follows
A mailing list is the one communication channel that belongs to the sender. No algorithm sits between us and our members. Mailchimp integration is built into the site and pending final configuration. Once live, it replaces the unreliable reach of social media with a direct line to people who opted in.
Tech Stack
- Framework: Next.js (static export)
- Hosting: GitHub Pages with custom domain
- CMS: Decap CMS (Git-backed, browser-based)
- Typography: Space Mono + Inter
- Visual: Dark theme, neon accents, scanline overlay, glitch aesthetic
- Email: Mailchimp (integration built, pending final config)
- SSL: Auto-provisioned via GitHub Pages
- CI/CD: GitHub Actions on push to main
Outcome
The site is live at paug.net. DNS is configured, SSL is active, real content is published, and all three founders are represented. PAUG has a home that it owns. Members can find events without hoping the algorithm surfaces a post. New people searching for "Pittsburgh Ableton User Group" land on a real site with real information instead of an abandoned Facebook page.
For a community that has been running for about ten years, having a permanent address on the internet is overdue. It changes how we talk about PAUG: instead of "find us on Facebook," it is "go to paug.net." That sounds small. It is not.
What I'd Do Differently / What's Next
- Decap CMS onboarding for Steve: The CMS is set up but Steve has not used it solo yet. The real test is whether he can post an event without asking me anything. That walkthrough needs to happen and any friction points need to get smoothed out
- Mailchimp integration: The signup form is built into the site structure. Final Mailchimp configuration and testing is next. Once that is live, we can actually communicate with members directly
- Event RSVP system: Right now events are informational. A lightweight RSVP or "I'm interested" feature would give us signal on expected attendance, which helps with venue planning
- Content velocity: The site only works as a community hub if it gets updated regularly. The CMS makes that possible technically, but the human habit of actually posting still needs to develop. That is a design problem too, just not one you solve with code
- Analytics: Some lightweight, privacy-respecting analytics would help us understand whether people are actually finding and using the site. Nothing invasive, just enough to know if the thing we built is working