Most indie devs and vibe coders ship fast, deploy on Vercel or Cloudflare, and just wait for the invoice. Nobody reads the pricing docs until the bill hurts. Here's what's actually driving hosting costs in 2026 — and what we changed on ihatereading.in to keep our Vercel and Firebase bill under $100/month at 10,000 visitors.
It's Not "Hosting." It's CPU Billing
In 2026, most websites are built on React, Next.js, or Vite — increasingly with TanStack on top of one of those two. Building is free. Hosting is where the real, often hidden cost lives, and that cost comes down to one thing: CPU computing, whether you're running your own server or paying a third party to run it for you.
Next.js categorizes server-side API work as Fluid Compute, and every server-side request adds to the bill. Vercel's own documentation confirms this directly: Fluid Compute meters three things per request — Active CPU (the milliseconds your code actually executes), provisioned memory (GB-hours your function instance stays warm), and invocations. The Hobby plan includes 4 CPU-hours, 360 GB-hrs of memory, and 1 million invocations for free; cross that on Pro and you're paying $0.60 per extra million invocations, plus regional CPU and memory rates stacked on top (Vercel Fluid Compute Pricing).
Cloudflare Workers runs on the same underlying principle but bills CPU-time instead of wall-clock time. Workers Paid costs $5/month and includes 10 million requests plus 30 million CPU-milliseconds; beyond that it's $0.30 per extra million requests and $0.02 per extra million CPU-ms (Cloudflare Developer Platform Pricing). The forgiving part on both platforms is that waiting on a database call or an external API doesn't burn CPU time. The expensive part is that every server-side route you hit still counts as a full invocation, every time.
There's a quieter version of this trap baked into Next.js itself: Incremental Static Regeneration. ISR looks free because the page is "static," but Vercel's own docs are explicit that adding a revalidate window spins up a serverless function behind the scenes, and that function re-runs on the schedule you set (Vercel ISR docs). A page that revalidates every 10 seconds isn't static from a billing standpoint — it's a recurring invocation, forever, whether or not anyone reads that page that minute.
Most websites can run free on Vercel or Cloudflare up to about a thousand visitors. Past that, the meter starts running, and people go looking for alternatives to bring the bill back down.
The Gaps Most Vibe Coders Skip
The few gaps most developers and vibe coders overlook are the main reason CPU usage — and the bill — climbs. We build, integrate APIs, add pages, plug in databases and tools, deploy, and hope we don't get hit with a surprise invoice at month's end. Once you understand what's actually adding to the cost, you're in a position to increase or decrease the bill deliberately, instead of finding out after the fact.
I built a Vercel and Cloudflare usage-costing skill specifically for this: copy the skill prompt, hand it to any coding agent — Claude, Cursor, or Codex — and get back a detailed costing report table, built against current pricing for each platform and your actual visitor volume, before you ever see the invoice. It's the same instinct behind how we run our content pipeline for under $10 a day — know the meter before you scale the thing that runs on it.
What We Actually Changed on ihatereading.in
- Static-first rendering. Most of our content doesn't change per request, so we render it static instead of hitting Firebase server-side on every load. A static page is a free CDN hit; a Firebase read on every visit isn't — and that difference matters once you're scaling toward 10k visitors a month. This is the same principle behind building the simplest, quickest blog website on Next.js and React: static content doesn't need a server round-trip to exist.
- No unnecessary server-side APIs. We either call APIs client-side in the browser, which costs the platform nothing, or route through a dedicated backend hosted on Fly — cached or on the free tier — instead of letting every request eat into Vercel's invocation and CPU meter.
- Reduced ISR usage and server-compute dependencies, pushing logic to client-side, browser-based libraries instead of adding another server round-trip. Every
revalidatewindow you skip is one less recurring function invocation on the bill. - Aggressive data caching, which directly cuts request load on both platforms' metered layers, and matters more the bigger your traffic gets.
Cost and Performance Aren't the Same Axis
Most developers believe cost is directly proportional to performance. You can boost performance and user experience by putting everything server-side — ISR, server-based CPU computing — and it will absolutely improve speed. It will also hand you a long bill. Building fast is easy. Building performant and cheap is hard.
To push cost close to zero, the natural end point is Vanilla JS — no servers, no APIs, no CPU involved, hence no cost. The historical problem was needing React for interactivity. In 2026, AI coding agents make it realistic to move a website from React to Vanilla JS for two reasons: it's cheap (no server, no API, no CPU), and it's faster by default, since JavaScript is slow in the browser while plain HTML is fastest by nature.
Where that's too big a leap, Astro is the middle ground, and the numbers back it up. Astro ships close to zero JavaScript by default — one 2026 comparison measured about 9 KB of JS for an Astro page against roughly 463 KB for an equivalent Next.js page, a gap that shows up directly as a hosting bill difference, not just a Lighthouse score (Astro 6 vs Next.js 16 for content sites, dev.to). Cloudflare clearly sees the same case for static-first content: it acquired the Astro team in January 2026, and Astro still ships as open source. For a content site, that's markdown rendered as plain HTML at build time — no server, no CPU meter running per request, and it's a better setup for AEO (AI answer-engine visibility) on top of being faster and cheaper. Even search can move client-side and browser-based, keeping CPU spend low. All of these small changes compound as traffic grows.
Cheap Infra Means Nothing If Nobody Finds the Site
Reducing spend is only half the plan. The other half is making sure the site actually gets found — by Google and Brave, and increasingly by AI answer engines. This isn't a minor channel anymore: roughly 58% of consumers now use AI answer engines like ChatGPT, Perplexity, and Google AI Overviews during product research every week, and that share is climbing (HubSpot: Do backlinks matter for AEO?). The same research notes that contextually relevant backlinks still carry more weight for AEO than a pile of high-volume, low-relevance links — quality over quantity, same as classic SEO, just judged by a different reader now.
Practically, that means submitting to Reddit, YouTube, G2, Capterra, and Product Hunt; earning backlinks from high-DR platforms; and building SEO authority through articles and website content written for both human search and LLM citation. We cover the full free-to-paid version of this playbook — the complete growth playbook for getting free traffic in 2026 — and go deeper on the AI-citation side in our AEO guide for technical founders. If you're launching something new, our running list of SaaS directories is the fastest place to start submitting.
Cheap infra means nothing if nobody's finding the site. Get both right — the bill and the discoverability — and you're running a site that costs less than most people's coffee budget while still showing up where it matters.
More on this soon, and every month's changes land first in the iHateReading Magazine digest.
— Shrey