Pembroke Citizen Journal — Pembroke, Massachusetts
Where things stood
The Pembroke Citizen Journal is a small nonprofit local paper covering a town of about 18,000 people. When I got involved, the operation ran on what I'd charitably call the default stack for a volunteer organization: personal Gmail addresses for editorial correspondence, a Wix site that had to be hand-assembled for every publication cycle, and Word documents emailed back and forth between reporters, copy editors, and editors.
That last part is the one worth sitting with. There was no version control, no clear source of truth, and no way to know whether the draft in your inbox was the current one. Someone would edit a story, email it back, and someone else would edit a different copy in parallel. The reconciliation happened in people's heads.
None of this was anyone's fault. It's what you get when a group of committed people build a newspaper out of the tools they already have. But it capped what the paper could do. Publishing weekly wasn't realistic when every issue required that much manual coordination.
The part that took the longest wasn't building
Before I wrote anything, I spent a lot of time evaluating what already existed. That's the work I'd emphasize most, because it's the part that gets skipped.
The market for editorial and newsroom software is real, but it's priced for newsrooms with budgets. Most of what I trialed fell into one of three buckets: too expensive to justify at a nonprofit's scale, sold in bundles where we'd pay for a dozen features to get the two we needed, or technically capable but requiring a level of comfort with systems that a volunteer staff doesn't have and shouldn't need to acquire.
That third constraint drove more decisions than the budget did. The people using these systems every day are reporters and editors, not administrators. A tool that's powerful but demands ongoing technical babysitting isn't a solution — it's a dependency, and it fails the first week I'm not available. Anything that went in had to be operable by someone who doesn't want to think about it.
So a lot of the value here was in what didn't get purchased. Where nonprofit pricing existed, I found it and used it. Where a commercial product was overbuilt for the actual need, we didn't buy it. Where nothing on the market fit, building something small and purpose-specific turned out to be cheaper and more sustainable than adopting something large and wrong.
What I built
The public site. Ghost, on the Gazet theme, replacing Wix. The section architecture — Latest, Police Blotter, Real Estate, Environment, Events, Podcasts, Newsletters — was built to match how the paper actually organizes coverage rather than how a template assumed it would. Several content types the paper needed didn't exist in the theme: obituaries, Letters to the Editor, and a Police Blotter with the legal disclaimers that kind of reporting requires. Those got built. Underneath it all is a two-tier tagging system with SEO redirects, so the URL structure holds up as coverage grows.
Membership runs through Stripe at nonprofit pricing, with six support tiers plus one-time donations. Every customization — routes, redirects, code injection, theme changes — is version-controlled, so the site is recoverable rather than existing only as a series of settings someone once clicked.
Google Workspace. The organization moved off personal email onto a proper Workspace tenancy. A break-glass superadmin account sits separate from day-to-day administration. Six shared drives replace the email-attachment shuffle. Role-based groups — reporters, copy editors, editors — drive both distribution lists and document access, so permissions follow the newsroom's actual structure instead of being maintained by hand. Role addresses route into editorial workflows. Org-wide 2FA is enforced, external sharing is off, and unused services are disabled.
The Editorial Hub. A custom web application for the editorial team, built in JavaScript and Python. This is what replaced the emailed-documents problem. It runs self-hosted on Proxmox in Docker with separate development and production environments, CI/CD through self-hosted GitHub Actions runners, a backed-up database, and a documented disaster-recovery path. It's reachable over the internet through a Cloudflare Tunnel with Access in front of it — no open inbound ports, no VPN for users to fumble with.
Building custom software is usually the wrong answer for a small organization. It was the right one here because the alternative was a subscription the paper couldn't sustain, wrapped around features it would never use.
The MLS Report Importer. A smaller tool that solves one annoying, recurring problem. Every week the paper publishes real estate listings from an MLSPIN PDF, and every week an editor was hand-formatting that report into the site. Now: upload the PDF, click Copy, paste into Ghost. Python and FastAPI, stateless, gated by Cloudflare Access, with listing photos cached in Cloudflare R2.
It took a fraction of the time the Editorial Hub did and it removes a recurring chore permanently. Those are often the best projects.
What changed
The paper publishes weekly now. That's the outcome that matters, and it wasn't a technology goal — it was an editorial one that the previous setup made impractical. Coordination that used to happen through inbox archaeology now happens in a system built for it.
The security posture went from personal accounts and shared passwords to enforced 2FA, role-based access, and an administrative account structure that survives someone leaving. For an organization publishing police blotter items and covering town government, that matters more than it might for a business selling widgets.
And the whole thing is documented. Systems, account ownership, recovery procedures — written down for whoever inherits it, whether that's a future volunteer or a paid administrator. An organization that depends on one person knowing how everything works has a single point of failure wearing shoes.
What I'd tell another organization
The instinct when technology is holding you back is to go buy something. Usually the more useful first question is what you're actually trying to do, and whether the thing you're about to buy does that or just does a lot.
Most of the value I added here came before any building started: understanding the newsroom's real workflow, finding nonprofit pricing where it existed, and being willing to say that a well-reviewed product was wrong for this organization. The systems that got built were shaped by the constraint that non-technical people had to run them every day without help.
That's the same approach I bring to small business work — figure out what's actually needed, be honest about what isn't, and build only where buying doesn't fit.
The Pembroke Citizen Journal is both a client and an organization I've become more involved in as a volunteer. Roughly 100 hours of work across the project, spanning site development, Workspace deployment, custom application development, and self-hosted infrastructure.