Creekside Shores Portal

This project started the way a lot of volunteer work starts: an email I almost didn’t open.

I’m an owner and resident at Creekside Shores. One afternoon a message went out from the current HOA board. The gist was that they were looking for enough homeowners to volunteer for the upcoming board term — and, buried a little further down, the proposed 2026 budget. I read the whole thing twice.

Two things jumped out.

The first was a clause I had glossed over when I bought the house: our bylaws require the HOA to hire a third-party property management firm if not enough homeowners volunteer to run the board. That is not a small line item. That is a standing, recurring expense that shows up in everyone’s dues, forever, because a handful of neighbors didn’t want to sit in meetings. I did not want to pay for that. More specifically, I did not want to watch my own dues go up to pay for it.

The second was a line in the proposed budget for hiring a web designer to build a community site. The board had already concluded the neighborhood needed a real, board-owned communication channel, and the plan on the table was to contract it out.

I’m a software engineer. I already host things on Cloudflare. I know what a portal for a couple hundred households looks like, and it is not a thing you should be paying a web design firm to build from scratch. So I replied to the email and volunteered to build it — as a homeowner, before the board term I’m now running for had even started. The motivation was not resume-building. The motivation was not paying for something I could do myself, and not letting the community pay for it either.

This is the kind of thing I actually like. A real problem with real constraints, a small group of people who just need it to work, and no appetite for anything fancy. Nobody wants to hear about architectures. They want a place where the board can post an update, homeowners can read it, the record survives, and nobody has to call a lawyer.

On the “nobody has to call a lawyer” part: there’s context. The neighborhood has had a Facebook group for years, and for a while it doubled as the board’s informal announcement channel. That ended when a homeowner tried to post some personal relationship drama on the group’s feed, the board moderated the post, and the homeowner threatened to sue the board for a First Amendment violation — their reading, not the law’s. The HOA’s lawyer advised the board to step away from administering the group entirely, because a volunteer board moderating a private social platform is a risk vector nobody on the board is paid enough to absorb. Another resident volunteered to take over the group as a non-board admin. The group still exists. It’s the unofficial social channel for the neighborhood now, run by a neighbor, not the board. The portal is the board’s official channel. They’re not competing — they’re just finally in the right lanes.

I made one big decision early and everything else followed from it: Cloudflare-first. That’s not a resume bullet — it’s a practical choice for a volunteer-run HOA with zero on-call rotation. The free tier covers a staggering amount of what a small community actually needs. The global edge means the site is fast from anyone’s couch. And when something does go wrong at 11pm, it tends to be a deploy issue I can roll back, not a server I have to SSH into and rescue.

The site itself is Astro. Static where it can be, dynamic where it has to be. Most of what a homeowner sees — documents, announcements, the directory of who does what on the board — is content that doesn’t need to be rendered on every request. Astro’s mix of static output and selective interactivity fits that shape exactly.

Identity is Better Auth. The board needed something that could handle real-world messiness: homeowners who share an email with a spouse, renters who aren’t owners but still need access to certain things, board members with elevated permissions, and the slow trickle of people who move in, move out, or forget their password once a year. Better Auth gave me session management, email verification, and role boundaries without me having to hand-roll any of it. Sessions sit in Cloudflare KV, which means auth checks are fast from anywhere the site is served.

The data layer is Drizzle against Cloudflare D1. D1 is SQLite at the edge, which sounds unusual until you realize that an HOA portal is, at its heart, a small amount of important data read by a small number of people. It’s the right size database for the problem. Drizzle gives me type-safe queries and migrations that run in CI, so schema changes aren’t a thing I do at midnight with my fingers crossed.

Documents — meeting minutes, financials, covenants, the PDF of the rules everybody signed and nobody reads — go into R2. R2 is cheap, it doesn’t charge egress, and for an HOA that occasionally gets a burst of traffic when something contentious happens, “doesn’t charge egress” is not nothing. The archive is the product here. If the archive costs more to maintain than the HOA can justify, the project fails. R2 makes that math stay boring.

Outbound communication is where it gets interesting. The board needs to send notifications — meeting reminders, dues notices, emergency alerts about things like a water main break. Some of those go out by email (SendGrid), some by SMS (Twilio), and the scheduling has to survive the board member who queues it up on a Sunday night and then goes to bed. That’s what Cloudflare Queues is for. A board member schedules a notification, it lands in a queue, and a worker picks it up when it’s supposed to go out. If SendGrid hiccups, the job retries. Nobody has to babysit it.

Then there’s the in-app side. When a homeowner is actively on the site and something relevant happens — a new document gets posted, a reply comes in on a board announcement — I wanted that to feel alive, not require a refresh. That’s Durable Objects. Each active session can open a realtime channel, and the DO fans updates out to the right people without me having to run a separate websocket service or pay for a third-party pub/sub.

What all of that adds up to, from the board’s perspective, is undramatic in exactly the right way. They log in. They post. Homeowners get notified through whichever channel they’ve opted into. The post sits in the archive, signed, timestamped, and searchable. If a dispute comes up six months later and somebody asks “what did the board actually say about the short-term rental rule,” there’s a single answer and a link to it.

The community isn’t paying a property management firm. The community isn’t paying a web designer. The board owns its channel and its archive. The monthly Cloudflare bill is small enough that nobody has to defend it at the annual meeting.

It’s not a flashy project. It’s the kind of thing you build once, maintain lightly, and forget about — which, for an HOA portal, is the entire point.