Most "developer tool stack" posts are shopping lists. This one has a stricter rule: if it is not currently running this site, it is not on the list. Everything below can be verified from the repository, the DNS records, or the HTTP responses of yangworks.dev.

That rule cuts out a lot. There is no analytics tool here, no CMS, no framework, no bundler, no design tool, no issue tracker, and no newsletter platform — not because those are bad, but because this project does not run them. The last section of this article says what "absent" actually means.

Hosting, DNS, and email: Cloudflare, three products

Workers Static Assets serves the site. The configuration is four asset settings and no Worker script. Why it: the deployment contract lives in wrangler.jsonc in the repository rather than in a dashboard, and adding server-side code later is a config key rather than a replatform. What I did not choose: Cloudflare Pages, which still works and which this site migrated off — the differences are in the Pages versus Workers comparison, and the two-month verdict is in the review. Cost: free tier; Cloudflare's pricing page states requests to static assets are free and unlimited.

Cloudflare DNS holds the zone. Why it: the custom domain, the Workers deployment, and email routing are all one account, and Workers documents custom domains on off-Cloudflare nameservers as unsupported — so keeping DNS here is not really optional given the hosting choice. Cost: free.

Cloudflare Email Routing handles hello@yangworks.dev. The zone's MX records point at route1, route2, and route3.mx.cloudflare.net with an SPF record including _spf.mx.cloudflare.net. Why it: a publication needs a contact address that is not a personal Gmail, and forwarding into an existing inbox is less to maintain than a mailbox. The limitation: routing is not a mailbox. Replies do not go out from the domain — Cloudflare's Email Sending is a separate beta on the Workers Paid plan. What I did not choose: Google Workspace or Fastmail, either of which would give a real sendable mailbox for a monthly fee. Cost: Email Routing is available on Cloudflare's Free plan.

Source and CI: GitHub, with the pipeline on Cloudflare's side

The repository is on GitHub with main as the production branch. There is no .github/workflows directory. Cloudflare Workers Builds is connected to the repository and runs npm run build followed by npx wrangler deploy on a push to main.

Why it: one pipeline instead of two. A GitHub Actions workflow that builds and then calls wrangler deploy would duplicate what Workers Builds already does. What I gave up: tests do not currently run in CI — npm test runs locally, and a push to main deploys whether or not it passed. That is the weakest link in this stack and I am naming it rather than describing it as simplicity. Cost: free — the repository is private, and GitHub's Free plan covers unlimited private repositories with a limited feature set.

Build: Node.js and nothing else

package.json declares zero dependencies and zero devDependencies. The build is a Node script that deletes public/, copies three source directories into it, runs the handbook and publication generators, and writes the sitemap, language-root stubs, and 404 page. It finishes in roughly 0.2 seconds and produces 75 files.

Tests use node --test, the runtime's built-in test runner.

Why it: a site this size does not need a build system, and every dependency is something to update. What I did not choose: Astro, Eleventy, and Hugo would all handle this comfortably and would have saved me writing an i18n availability model, a sitemap generator, and a publication registry by hand. The honest trade: that custom code is now infrastructure I maintain. A framework would have moved the work, not removed it — but it would have moved it onto someone else's maintenance schedule, which is worth something. Cost: free.

One inconsistency worth admitting: .nvmrc pins Node 20 and the machine that builds locally is on 22.14.0. Nothing has broken, because the build only uses long-stable built-ins, but the pin does not currently describe reality.

Deploy: Wrangler

Wrangler 4.63.0, invoked as npx wrangler deploy. Why it: it is the supported way to deploy a Workers project and it reads the same checked-in config that Workers Builds uses, so a local deploy and a CI deploy do the same thing. Cost: free.

Writing: HTML fragments and a metadata registry

Articles are plain HTML fragments in src/publication/content/. Their metadata — title, dates, test scope, evidence, sources with the date each was checked, affiliate status, related links — lives in a single JavaScript registry that the build validates. Publishing is a status field.

Why it: the validator is the point. It refuses to build a published article missing a required field, with an unresolvable internal link, or with an unfinished marker left in the body, and it keeps draft URLs out of the sitemap. That is editorial policy expressed as a build failure rather than as a promise. What I did not choose: Notion, Ghost, and WordPress all offer a better writing experience and none of them would let me express "an article cannot be published without a checked source date" as a hard error. Cost: free.

Claude Code is used for drafting and for repository work; the repository contains a CLAUDE.md with the project's rules. Every published sentence is reviewed by a human before it ships, and the editorial policy states this in full. Cost: a paid subscription — the one line item here that is neither free nor strictly required.

Typography: Google Fonts

Inter, loaded from fonts.googleapis.com and fonts.gstatic.com. Why it: it was the fastest way to get consistent typography across three writing systems. The cost is not money. It sends every visitor's request to a third party, which is why the privacy policy discloses it. Self-hosting the font files would remove that dependency, and it is on the list of things to fix.

Analytics: none

The site runs no analytics script and sets no cookies of its own. The only traffic data is Cloudflare's aggregate request statistics.

Why: partly a privacy position, partly that a site this new has nothing to measure. What it costs me: I cannot tell you which of these articles anyone reads, and I cannot make a claim about traffic anywhere on this site — which is a constraint I would rather have than a number I would be tempted to round up.

What this stack is bad at

  • Collaboration. Everything here assumes one person who can read a diff. Handing this to a non-technical editor would require building a layer that does not exist.
  • Release safety. Push to main is production, and tests are not enforced in CI.
  • Scale of content. A full rebuild on every change is right at 75 files and wrong at 10,000.
  • Anything dynamic. No auth, no database, no forms. Those need a Worker script, which the platform supports and this project does not yet use.

Costs, honestly

Every hosting, DNS, email, source-control, and build tool in this list is on a free tier and none of them is free because of a trial. The domain registration is the only recurring infrastructure cost, and the Claude Code subscription is the only recurring tooling cost. There is no affiliate relationship with any product named in this article, and no commission is earned from any of them.

What "not on the list" means

Vercel, Netlify, Astro, Tailwind, Plausible, Fathom, Ghost, Linear, Figma, and every other good tool that is not mentioned above are absent for exactly one reason: this project does not run them. That is not a verdict. A tool I have not operated is a tool I cannot review, and the fastest way to make a stack article useless is to pad it with things the author read about.

Yangworks is also building Upwork Toolkit, a browser extension currently in development. It is listed here for disclosure, not as part of the stack — it is a product this project makes, not a tool this project uses.

If you want the reasoning behind the hosting choice in more depth, start with the deploy guide.