Archive note, June 17, 2026: This post is based on SoCalNomad operational documentation through mid-2026.
The longer SoCalNomad ran, the less the interesting work looked like feature development.
It looked like operations.
That is not a complaint. It is what happens when a project becomes real. Once people and crawlers can reach it, every change has a blast radius. Every cache has a memory. Every workflow has a schedule. Every “temporary” script becomes suspiciously permanent.
Documentation Became Infrastructure
The project documentation eventually became a system of its own:
- Current status.
- Resume notes.
- Troubleshooting.
- Quick reference.
- Architecture documents.
- Archived session logs.
- Deployment procedures.
That may sound excessive for a solo project. It was not.
AI-assisted development made documentation even more important, not less. Each session needed enough context to avoid rediscovering old decisions. The project was too broad to keep everything in working memory: WordPress, calendar, PostgreSQL, n8n, Cloudflare, Revive, Search Console, and social automation all had their own traps.
The docs became the external memory of the platform.
Moving Past n8n Was A Turning Point
One of the larger operational lessons was that n8n was valuable for discovery and painful as the long-term home for the pipeline.
The early workflows helped prove the shape of the system: ingest feeds, filter them, cluster related items, synthesize articles, and publish drafts. That visual model was useful while the problem was still being understood.
It became less useful as the system matured.
The shortcomings were practical:
- Workflow validation state could become stale and block execution before a node ran.
- Agent nodes could loop on tool calls until hitting iteration limits.
- Complex branch and item-index behavior made some bugs hard to reason about.
- API-imported workflow changes still needed UI touches to refresh validation.
- Version control was weaker than ordinary code review.
- Reproducing and testing behavior was harder than running a script.
The answer was not to make a more elaborate n8n graph. SoCalNomad moved core automation into Python scripts and cron. The pipeline became ordinary code: ingest, filter, cluster, synthesize, publish, generate images, and enrich from the data mart. Calendar grouping moved to direct SQL on PostgreSQL. n8n was eventually marked inactive, with all workflows disabled.
That was not a retreat from automation. It was automation becoming production software.
The Same Mistakes Had To Become Impossible
A recurring operational theme was turning painful incidents into procedures:
- Cache stale? Write the purge recipe.
- Wrong environment? Document the dev/prod trap.
- Workflow silently failed? Add a health check.
- Theme source drifted? Repoint deployment and add a guard.
- Sitemap broke? Record the cause and verification path.
- Container restarted without code changes? Document rebuild versus restart behavior.
- n8n became the wrong abstraction? Replace it with testable scripts and scheduled jobs.
The goal was not perfection. It was making each class of mistake less likely to repeat.
That is the difference between tinkering and operations.
Home Production Is Still Production
Running from home infrastructure can create a false sense of informality.
It is easy to think: this is just my server, my fiber line, my project.
But public production does not care where the machine lives. If Googlebot sees the site, if users load pages, if affiliate links exist, if ads render, if articles publish, then the system is production.
That realization changed the standards:
- Backups needed to be restorable.
- Deployments needed repeatable commands.
- Caches needed clearing paths.
- Public endpoints needed security review.
- API data needed validation.
- Search Console issues needed tracking.
The infrastructure was modest. The responsibilities were not.
The Black Box Became A Product
The phrase “black box solution” fits because the successful version hid its complexity.
Readers did not need to know whether an event page came from a static export, a PostgreSQL API, or a WordPress template. Google did not need to know that Cloudflare was fronting a home origin. Advertisers did not need to know how Revive was wired into the theme.
They needed the system to behave.
That external simplicity required internal discipline.
What I Am Proud Of
I am proud that the project grew from practical constraints rather than ideal architecture diagrams.
It used open-source tools because budget mattered. It used Cloudflare free services because they solved real edge problems. It used a home Proxmox environment because that was available. It used WordPress because publishing mattered. It used PostgreSQL because operational data outgrew posts. It moved from n8n workflows to Python and cron because production needed testable code. It used documentation because memory did not scale.
The result was not a toy.
It was a production-capable media platform engineered from ordinary parts, on a residential fiber connection, with enough discipline to look normal from the outside.
That is the part worth preserving before the infrastructure changes.