Archive note, September 27, 2025: This post is based on early SoCalNomad project documentation from September and October 2025.
SoCalNomad started with a modest public premise: Southern California entertainment, events, photography, and local culture.
The engineering premise was less modest. I was not trying to stand up a brochure site. I was trying to build a small media platform that could collect event information, publish original and automated coverage, organize artists and venues, serve advertising, and survive in production without a cloud budget.
That distinction changed nearly every technical decision.
The First Shape Of The System
The earliest architecture was segmented by responsibility:
- WordPress for the main editorial site.
- A calendar application for event discovery.
- Automation workflows for RSS ingestion and content processing.
- A future artist and venue directory.
- Analytics and ad-serving planned as separate concerns.
This was more infrastructure than a hobby blog normally deserves, but the project was not trying to be normal. It needed to support photography, automated news, affiliate event discovery, advertising, and eventually a searchable Southern California entertainment directory.
The project documentation described the goal as a self-owned media brand. That phrase mattered. Publishing on someone else’s platform is distribution. Owning the publishing stack is leverage.
Why The Stack Became Modular
The tempting approach would have been to make WordPress do everything. WordPress can host posts, custom post types, event pages, media, menus, ads, and plugins. It is flexible enough to absorb almost any feature until it becomes responsible for too much.
SoCalNomad went in a modular direction instead.
The main site stayed WordPress because that is where editorial content belonged. The calendar became its own frontend because event browsing has different performance and interaction needs than reading a post. Automation lived beside the site rather than inside it because feed processing, AI filtering, and scheduled jobs are operational workloads, not page-rendering workloads.
That split produced more moving parts, but cleaner failures. If the calendar API had a problem, WordPress did not have to go down. If a feed workflow failed, the public homepage could keep serving cached content. If the theme needed work, the automation data mart did not need to care.
Production On Residential Fiber
The project ran on a home Proxmox environment behind a residential fiber connection with a business account. That was a constraint, but not an embarrassment.
The design had to assume that the public internet should never see the home network directly as a casual collection of services. Cloudflare became the front door. Apache and ISPConfig handled web hosting. Internal services stayed internal unless they were intentionally exposed through narrow proxy paths.
That is the “black box” part I am proud of. To a reader or crawler, the site needed to behave like ordinary production infrastructure. Behind the scenes, it was a carefully arranged home lab with enough discipline to act like a real platform.
Cloudflare’s free tier was indispensable. It supplied DNS, TLS, CDN behavior, caching, and a public edge that made a home-hosted platform less fragile. It did not eliminate the need for good origin behavior, but it made the architecture viable.
The Platform Was Built Around Future Loops
The interesting part of SoCalNomad was not any single component. It was the loops between them.
The newsfeed could identify artists, venues, and events. The calendar could expose event data to readers. The directory could eventually turn repeated appearances into durable artist and venue pages. Editorial posts could link into the calendar. Calendar pages could support affiliate traffic. Ad serving could monetize the attention that made it through the system.
That is a platform loop, not a theme customization.
Early documentation already pointed toward this:
- News Feed → Calendar → Artist Directory.
- Multi-source entertainment journalism.
- Event discovery with affiliate links.
- Photography and original coverage layered over automated intake.
The site was small, but the system was designed as if the data would matter later.
A Scrappy System Still Needs Standards
The funny thing about budget constraints is that they punish sloppiness. If you are not buying managed services, you need habits.
SoCalNomad accumulated standards around Docker directories, documentation, deployment notes, local development, environment separation, cache clearing, backups, and operational checklists. Some of that felt heavy at the time. Later, it became the difference between a home project and a production system I could reason about.
The origin story is not “I built a website at home.”
It is closer to this:
I built a small media platform from modest infrastructure, then kept forcing it to behave like production until the outside world could not tell where it lived.