Pembroke Citizen Journal — Pembroke, Massachusetts
Where things stood
The Pembroke Citizen Journal is a small nonprofit paper covering a town of about 18,000 people, run by volunteers. When I got involved, it ran on what most volunteer groups end up with: personal Gmail addresses, a Wix site that had to be put together by hand for every issue, and Word documents emailed back and forth between reporters, copy editors and editors.
The emailed documents were the real problem. There was no way to know whether the draft in your inbox was the current one. One person would edit a story and send it back while someone else edited a different copy, and sorting that out happened in people's heads.
None of this was anyone's fault. It's what happens when people who care about local news build a paper out of the tools they already have. But it limited what the paper could do. Publishing every week wasn't realistic when every issue took that much coordinating.
Most of the work happened before I built anything
Before I wrote any code, I spent a lot of time trying what already existed. It's the part I'd point to first, because it's the part that usually gets skipped.
There's plenty of newsroom software out there, but it's priced for newsrooms with budgets. Most of what I tried was too expensive for a small nonprofit, came bundled with a dozen features we'd pay for to get the two we needed, or was capable but too technical for a volunteer staff to run.
That last one drove more decisions than the budget did. The people using these systems every day are reporters and editors, not IT people, and they shouldn't have to become IT people. A tool that needs me to keep it running stops working the first week I'm not around. Whatever went in had to be something a non-technical person could use without thinking about it.
So a lot of the value was in what we didn't buy. Where nonprofit pricing existed, we used it. Where a product did far more than we needed, we passed. Where nothing fit, I built something small that does one job well.
What I built
The website. I moved the paper from Wix to Ghost, a publishing platform made for news sites and newsletters, on a host that specializes in it. The sections follow how the paper actually covers the town: Town Hall, Public Safety, Schools, Community and Business. The weekly columns (Police Blotter, Pet of the Week, Question of the Week, Trash Talk, Senior Corner, Real Estate Snapshot and Where Is It) each have their own page so this week's is easy to find, and most of them have a spot on the home page too.
Some things the paper needed didn't come with the site's design, so I added them: obituaries with their own layout, letters to the editor, and a Police Blotter with the legal disclaimer that kind of reporting needs.
Readers can support the paper through six membership levels, from free up to $100 a month, or with a one-time donation, all through Stripe at its nonprofit rate. The site is also set up for local advertising. An ad service fills the ad spaces, so selling or swapping an ad never means changing the site. Obituaries never show ads.
A few smaller details matter for a paper like this. When a reader clicks a link out of an obituary or a Police Blotter item, the site they land on can't see which page they came from. Before we tried a new analytics tool, I read through its code to make sure it doesn't set cookies, because the privacy policy promises readers they'll be told if that ever changes. And the banner across the top of the site is styled as a red alert, because it's for breaking news and emergencies, not promotions.
Every customization is saved in a separate record, and the bigger changes come with notes on what changed, why, and how to undo it. The site doesn't exist only as settings someone clicked once and forgot about.
Google Workspace. The paper moved off personal email onto its own Google Workspace. Everyone has a PCJ address with two-step verification required, and files live in six shared drives instead of email attachments. Access follows the newsroom's roles: add someone to the copy editors group and they get the right drives and email lists at the same time. Letters to the editor and obituary submissions come in through their own addresses. Sharing outside the organization is off, and services nobody uses are turned off. There's also a separate emergency admin account that stays out of day-to-day use, so a problem with my account can't lock the paper out.
The Editorial Hub. This is what replaced the emailed Word documents. It's a web app I built for the newsroom, and every story lives in it from the first pitch until it's ready to run.
A story starts as a pitch on a shared board. An editor approves it, assigns a writer and sets a deadline. The writer drafts in the Hub. Copy editors suggest changes, a lot like track changes in Word, and the writer accepts or rejects each one. An editor does a final review and sends it over to the website, ready for that week's issue. When a story is ready for the next person, they get a ping in Google Chat, and deadlines turn amber, then red, as they get close. Only one person can edit a story at a time, and every saved version is kept, so you can see exactly what changed.
It also handles the repetitive parts of putting out a weekly paper. Regular columns start from templates with the date and banner image already filled in. Obituaries ask for the dates and format themselves. Interview notes, documents and links stay attached to the story they belong to, so they're still there months later when a correction or follow-up comes up. Videos are converted so they play on any phone. And there's a plain-language help guide built in, written for each role.
Staff sign in with their PCJ Google account. The Hub runs on a server I manage, with a test copy and a live copy, so changes get tried out before anyone on the team sees them. It's reachable from anywhere, but only after Cloudflare confirms you're on the PCJ team, and nothing on the network it runs on is opened up to the internet. Changes are tested automatically before they go out, and the database is backed up, with written steps for rebuilding the whole thing on another machine.
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 keep paying, for features it would never use.
An AI reviewer that can only suggest. The newest addition is an AI first reader, built on Anthropic's Claude. When a story reaches the editor, it reads the draft against AP style, the paper's own style guide and its ethics policy, and leaves notes the way a copy editor would. It can suggest small fixes to grammar and wording, but it can't change anything inside a quote, can't change a name or a number, and can't rewrite more than six words at a time. Anything about facts, fairness or ethics comes to a person as a question, not a fix. It never edits the story, never moves it along and can't publish anything. Those limits are built into the code and tested every time the code changes, so they don't depend on the AI following instructions. If sources are attached to the story, it checks quotes, names and figures against them. A typical review costs well under a dollar, and drafts sent for review aren't used to train the model.
Weekly home sales. Every week the paper publishes local home sales from an MLS report that comes as a PDF, and every week an editor was formatting it by hand. I first built a small separate tool for it, and it has since been folded into the Hub: drop in the PDF, check the list, and the sales go into the story with their photos. It took a fraction of the time the rest of the Hub did, and it took a weekly chore off someone's plate for good. Those are often the best projects.
Making sure it doesn't depend on me
A paper where one person knows how everything works is one bad week away from trouble, and for a while that person was me. A good share of the work since has gone into handing over the keys.
The paper has its own password vault now, owned by the nonprofit. The president and vice president can get into the email, the Hub's code, the payment account and the web address settings without me. Every system is written down: what it is, who controls it and what to do when it breaks, with a plain-English version for board members who don't want the technical details. A few accounts still depend on one person, either because the vendor doesn't support a second admin yet or because moving them now would cost money for no real gain. Those are written down too, with the plan for each.
What changed
The paper publishes weekly now. That's the outcome that matters, and it was never a technology goal. It was an editorial goal the old setup made impractical. Stories move through one system instead of a pile of email threads.
Security went from personal accounts and shared passwords to required two-step verification, access based on roles, and admin accounts that survive someone leaving. For a paper that publishes police logs, covers town government and runs obituaries, that matters more than it would for most small businesses.
What I'd tell another organization
When technology is holding you back, the instinct is to go buy something. Usually the better 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 what I added here came before anything got built: learning how the newsroom really works, finding nonprofit pricing, and being willing to say that a well-reviewed product was wrong for this paper. What did get built followed one rule: people who aren't technical have to be able to run it every day without calling me.
That's the same way I approach small business work. Figure out what's needed, be honest about what isn't, and only build where buying doesn't fit.
The Pembroke Citizen Journal is a client and also something I volunteer for. I report for the paper too, mostly on town government and public safety.