A community calendar, built in a weekend to run without me

What was there when I arrived

I came in to help the organization with social media, graphics and its website. Someone already had the website covered. What came up instead was a different gap: each group had its own website, its own Facebook page, its own email list. Events fell through the cracks, and people who would have shown up never heard about them.

There had been tries at a shared calendar. They were incomplete, and none let community members submit events.

They asked for help with social media because that was the problem they could name. My first job was finding the one underneath: there was no single place to find the community’s events.

Two more facts shaped the build. Whoever ran it would be a volunteer with limited technical experience. The volunteer hadn’t asked for the job and had plenty else to do. And because of the local political climate, the person approving events could not be visible anywhere on the site. That wasn’t a preference. It was a safety requirement.

Why not just buy something or hire

The test had three lines: it costs the organization nothing, the volunteer learns nothing new, and the volunteer’s name appears nowhere.

Website builders charge every month and still need someone managing a dashboard. An embedded calendar takes no submissions, and someone’s personal account stays attached to it. Event platforms keep the listings on someone else’s platform, with no single neutral address to hand the community. A freelance developer costs money and weeks the organization doesn’t have.

What I built

I built three pieces:

1. A public calendar. Events by date, filterable by group, with a preview that shows up properly when someone shares the link.
2. A submission form. Any community member can add an event, with no account and no CAPTCHA. A limit on submissions per hour, and a hidden field that only bots fill in, handle the spam.
3. Approval by email. When an event comes in, the volunteer gets an email with the details, an approve link and a reject link. It’s a single tap, with no login, dashboard or app. Each link works only once.

The volunteer’s identity was a design decision from the start, not a patch. Approval emails go to an organizational address and are forwarded from there, so the volunteer’s personal email isn’t in the code, the documentation, or anywhere on the site.

I made the design decisions and wrote them down precisely, including what not to do. An AI coding tool built to that spec, and I reviewed everything it produced. That’s where the weekend came from: the design work was finished before the build started.

The longer story, and the economics behind it, is in AI Just Broke the Economics of Giving a Damn.

The numbers

What the build caught

The AI put a personal email address in the documentation. It was in the project context, so it used it, on a project built to keep one person’s name out of public view. I caught it in review.

The first version let anyone read and change submissions. The database’s access rules were open to the public, the kind of shortcut that works in a demo. I closed every public route into the database, so every change goes through the server.

Events would have shown on the wrong days. The functions that check today’s date were marked as never changing, so the database could have kept returning a stale answer for today. Fixed in review.

These aren’t exotic bugs. They’re the kind of mistakes that ship when nobody reviews the AI’s code.

Who runs what

This one’s a donation, and I built it to run without me. There’s nothing for me to do week to week: no updates to push, no queue to clear.

The volunteer decides what goes on the calendar, and the groups write their own listings. It’s the community’s calendar.

What it cost, said out loud

It runs without upkeep, not without me. The hosting and the domain are mine, so if I stopped covering them, the calendar would stop.

One volunteer approves everything. If they’re away, new events wait in the inbox until they’re back.