The Economics of a 330-Article Blog: Hosting, Tooling, and Cost per Article

People assume a 330-article blog must cost real money to run. When I tell other developers that pickuma’s monthly infrastructure bill rounds to roughly the price of a coffee, the reaction is usually disbelief, then a question about traffic, then a quieter question about whether the numbers actually add up. So this is the honest teardown I wish someone had written before I started: where the money goes, where it doesn’t, and what the marginal cost of publishing one more article really is once the stack is built.

I want to be precise about what “we” means here. Pickuma is a small operation — mostly me editing, with AI assistance on drafting, which we disclose on every post. The numbers below are approximate and current as of mid-2026. I’m not going to fabricate exact cents, because the whole point of a cost teardown is that it’s trustworthy. Where I’m estimating, I’ll say so. Where a number depends on traffic that could change next quarter, I’ll flag that too. The headline, though, is stable: a static Astro site sitting on a CDN edge is one of the cheapest ways to publish at scale that has ever existed, and the cost structure is genuinely strange once you internalize it.

The Hosting Bill Is Basically a Rounding Error

The reason hosting costs almost nothing is structural, not clever. Pickuma is a static Astro site. Every article is rendered to HTML at build time and shipped as a flat file. There is no server rendering a page when you visit — there is a file, sitting on Cloudflare’s edge network, served from whichever data center is closest to you. A 330-article blog is, from the infrastructure’s point of view, a few thousand small files: HTML, a bit of CSS, some images, an RSS feed, a sitemap.

We deploy with Wrangler to Cloudflare Workers, and the static assets ride along on Cloudflare’s asset hosting. At our scale, this lives comfortably inside the free allotments. Cloudflare’s Workers free tier covers a generous number of requests per day, and static asset serving for a content site like ours doesn’t come close to the paid thresholds unless an article goes genuinely viral. Even then, the marginal cost of a traffic spike on static files is near zero, because you’re not paying for compute per request the way you would with a server-rendered app — you’re serving cached bytes. Bandwidth on Cloudflare’s CDN isn’t metered the way it is on traditional hosts, which removes the single scariest line item that kills hobby-scale content sites: the surprise egress bill.

The contrast that makes this concrete: if pickuma were a Next.js app doing server-side rendering for every article, each page view would invoke a function, and 330 articles getting steady traffic would mean a real, growing compute bill. Because we render once at build time and serve files forever after, traffic and cost are decoupled. More readers don’t cost meaningfully more money. That decoupling is the whole economic trick.

There’s a subtle failure mode hiding in this setup that I’ve written about separately: Cloudflare’s runtime can silently swallow a render error in an MDX file and deploy a zero-byte page rather than failing the build. We learned that the hard way and now guard against empty pages in the deploy pipeline. I mention it because “near-zero cost” should never mean “near-zero diligence” — the cheap stack still demands a verification step, and that step is engineering time, which is the currency that actually matters here.

Tooling: The Small, Real Line Items

If hosting is the rounding error, tooling is where the actual recurring dollars live — and even here, the totals are modest. Let me walk the line items honestly.

The domain is the one unavoidable fixed cost, somewhere in the range of $10 to $15 a year for a standard .com depending on the registrar and renewal pricing. Annualized to a monthly figure it’s about a dollar. That’s the floor; you cannot run a blog without it.

Supabase sits on the free or lowest paid tier. We use it lightly — the kind of structured data a content site needs, not a high-throughput application backend. For a publishing operation, the free tier covers a remarkable amount, and if you outgrow it the entry paid tier is around $25/month as of mid-2026. Whether you pay anything here depends entirely on usage; a pure static blog might never touch a database at all, in which case this line is zero.

Email and cross-posting is the fuzziest category because it scales with ambition. A newsletter service has a free tier up to some subscriber count, then pricing climbs. Cross-post and syndication APIs are often free or near-free for low volume. I’d budget this as “zero until you have an audience worth emailing, then a deliberate decision,” rather than a fixed cost from day one. Many sites overspend here early by buying audience tooling before they have an audience.

LLM API spend for AI-assisted drafting is the one genuinely new line item compared to how blogs were run five years ago, and it’s the most interesting because it’s variable per article. We use AI to produce first drafts that a human then heavily edits. The API cost of generating a draft for a long-form article — even with a capable model — lands in the range of cents to low single-digit dollars per article, depending on model choice, draft length, and how many revision passes you run. It is not the dominant cost. It is a seasoning, not a main ingredient.

Here’s the honest aggregate: infrastructure plus essential tooling for pickuma realistically rounds to under $5/month if you stay disciplined on the free and low tiers, with the domain being the only truly fixed obligation. Everything above that is a choice driven by audience scale, not a requirement of running 330 articles.

The Marginal Cost of Article Number 331

This is the number that actually shapes how you run a content site, so it deserves its own honest accounting. Once the stack exists, what does it cost to publish one more article?

The infrastructure answer, as established, is approximately nothing. The file gets built and shipped; storage and serving are inside the free tiers. The LLM draft costs a few cents to a couple of dollars. So the out-of-pocket marginal cost per article is, generously, under $3 and often well under $1.

But that number is misleading if you stop there, because it ignores the cost that dominates everything: editing time. An AI draft is raw material, not a finished article. Turning it into something worth a developer’s attention — verifying claims, killing fabricated specifics, restructuring weak sections, adding the hands-on detail that AI can’t invent, fact-checking pricing, writing an honest comparison — is hours of human work per piece. At any reasonable valuation of that time, the editing labor dwarfs the API and hosting costs by one or two orders of magnitude. The dollar cost is trivial; the attention cost is the whole game.

This inversion is the central economic fact of running pickuma. In the old model, infrastructure and bandwidth were a real tax on scaling content, and writing was “free” in the sense that it was just typing. In our model, infrastructure is free and the scarce, expensive resource is editorial judgment. That changes what you optimize. We don’t worry about server costs; we worry about whether we have the bandwidth to edit honestly. The bottleneck is quality control, and pretending otherwise — pretending the cheap stack means cheap publishing — is how content farms produce 330 articles that nobody trusts.

The Stack, Compared to the Alternatives

To make the “static on edge is cheap” claim concrete, it helps to position our stack against the realistic alternatives a developer would actually consider for a content site. The comparison is about cost structure, not just sticker price.

The pattern is clear once it’s laid out. WordPress on managed hosting is the default people reach for, and it works, but you pay a steady monthly fee that climbs as you grow, plus you’re running a database-backed dynamic app for content that almost never changes after publication. A Next.js SSR setup is the right call when you genuinely need dynamic rendering, but for a blog it means paying compute for every reader to regenerate pages that could have been static. A VPS gives you control but hands you the operational burden — patching, egress, uptime — which is just cost in a different currency.

Astro-on-edge wins specifically for the content-site shape: write rarely changes, reads dominate, and traffic should not translate into proportional cost. It’s not a universal “best stack.” It’s the best stack for this exact workload, which is the only kind of recommendation worth making.

Who Should Run a Blog on This Stack

This setup is a strong fit if you’re a developer comfortable with a build step, a git-based workflow, and deploying via CLI. If editing Markdown or MDX, running a build, and pushing to a CDN sounds routine rather than intimidating, the economics are hard to beat and the operational overhead is genuinely low. It’s especially good if you expect read-heavy traffic and want the peace of mind that a viral post won’t generate a frightening bill.

It’s a poor fit if you want a point-and-click CMS with no build step, if non-technical contributors need to publish without touching a repo, or if your site is fundamentally an application with per-user dynamic content rather than published articles. In those cases the static model fights you, and a hosted CMS or a server-rendered framework earns its higher cost by removing real friction. There’s no shame in paying for convenience when convenience is the actual constraint.

And a candid caveat on the AI-assisted part: this stack makes producing many articles cheap, which is a capability that cuts both ways. If you don’t have the editorial discipline to fact-check and rewrite every draft, cheap publishing becomes cheap slop, and the internet has enough of that. The stack lowers the cost of publishing; it does not lower the cost of being worth reading. Budget for the editing, not just the API.