How the network is built

Every site in the Simba Systems network is built the same way. Not because one stack fits every problem, but because running ten sites on ten different stacks is not something one person can maintain. The constraint shapes the architecture.

Static first

Each site is an Astro project that builds to static HTML, deployed to Cloudflare Pages by Direct Upload with Wrangler, not the Git integration. There is no server rendering a page per request. The data a page needs is exported to JSON ahead of time, and the page is built from that JSON. This is why every "data-driven copy" rule in this network's build prompts insists on numbers coming from a file at build time: it is not a style preference, it is the only way a static page stays honest.

No React, no UI framework. Vanilla TypeScript for the handful of things that need a script in the browser: a filter toggle, a chart tooltip, a nav menu. System fonts only. It sounds austere. It is also fast, and fast is a feature the whole network shares.

Dynamic pieces live in one Worker per site

The handful of things that genuinely need a server, a form submission, an uptime check, a small API, live in a single Cloudflare Worker per site, backed by D1 where storage is needed. This hub's Worker is workers/hub-api: it polls every live site for uptime, and it takes the advertiser and partner inquiry forms.

Pipelines run on one machine

Fetching and processing data happens on a Mac Pro on the local network, reached over Tailscale, never on the machine used for development. Every fetcher is idempotent, keeps its raw downloads by date, and fails loudly instead of silently publishing bad data. The canonical store is MySQL, also reached over Tailscale. The build never talks to MySQL directly: a pipeline script exports JSON into the repo, and that JSON is what the site builds from. If the pipeline is down, the site still builds, from whatever JSON was last committed.

This hub works the same way for its two data-shaped features: the site manifest registry (fetched daily from every network site's own /site.json) and the growth chart (fetched daily from the Cloudflare Analytics API). Both degrade gracefully. If a fetch fails, the last good data stands, and the failure is logged, not hidden.

Why write this down

If you are a data provider thinking about joining the network, or a developer curious how a one-person operation runs ten-plus sites without falling over, this is the honest version: static builds, one Worker each, one pipeline machine, and a lot of scripts that fail loudly instead of quietly. See Partners if you want in.