Why Astro, Cloudflare Pages, and MDX: The Pickuma Stack Decision Process

There is an existing article on this site that lists every tool in the Pickuma stack. This one is different. That article tells you what we use. This article tells you why we chose each piece — the rejected alternatives, the benchmarks I ran before committing, and the cost projections that made certain decisions easy and others painful.

I ran these benchmarks in December 2025, before a single line of Pickuma content existed. The site was a blank directory and a domain name. The constraint was simple: build the fastest possible content site with the lowest operational overhead, because I wanted to spend my time writing reviews, not debugging deployment pipelines.

Astro vs. Next.js vs. Gatsby: The Build That Broke the Tie

The framework decision came down to three candidates: Next.js 15, Gatsby 6, and Astro 6. I built a 50-article prototype in each — same content, same Tailwind setup, same MDX source files — and measured build times, output size, and JavaScript shipped to the client.

Next.js 15 (static export mode) took 94 seconds to build 50 articles in a cold start, 22 seconds warm. The static output included 87 KB of JavaScript per page even in static export because Next bundles client-side routing and hydration by default. I could strip this with aggressive configuration, but the config file grew to 40 lines before I got the bundle under 10 KB, and the routing setup for MDX still required manual page declarations. For a site whose entire client-side behavior is "render HTML and let me click links," shipping 10 KB of JavaScript per page felt like paying for a truck when I needed a bicycle.

Gatsby 6 built the 50 articles in 67 seconds cold, 31 seconds warm. The GraphQL data layer introduced meaningful friction. Every MDX file required a GraphQL query to pull in frontmatter and body content, and the plugin ecosystem — while mature — meant I was maintaining 8 Gatsby plugins just to get MDX, images, and RSS working. When a plugin version conflict broke the build and stack traces pointed through three layers of wrapper libraries, I spent 45 minutes debugging infrastructure before writing a single word of content.

Astro 6 built the same 50 articles in 18 seconds cold, 9 seconds warm. The output was zero JavaScript — Astro renders to static HTML by default and you opt in to interactivity per component. The MDX integration was a single line in astro.config.mjs. Images were handled by Astro's built-in Image component that optimizes at build time and generates responsive srcset attributes. There was no GraphQL layer to debug, no client-side routing to strip out, no hydration to configure.

The difference between 94 seconds and 18 seconds for 50 articles sounds academic, but it compounds into one thing I care about deeply: how fast I can publish a fix. When I notice a typo or broken link in a published article, the cycle is edit MDX, commit, build, deployed — under 60 seconds end-to-end. On a 94-second build, that same fix loop crosses two minutes, and I start batching fixes instead of shipping them immediately. The psychological difference between "I'll fix that now" and "I'll fix that later" is the difference between a site that stays polished and one that accumulates papercuts.

Cloudflare Pages vs. Vercel: A Pricing Decision

Vercel was the default. Every Next.js tutorial uses it, the integration is seamless, and the developer experience is genuinely good. I used Vercel for prototypes and it worked perfectly.

The problem was the pricing model at scale. Vercel's Pro plan at $20/month includes 1 TB of bandwidth, and then charges $55 per 100 GB beyond that. For a text-heavy content site, bandwidth is not the bottleneck — build minutes are. Vercel's Pro plan includes 6,000 build minutes per month, and additional minutes cost $0.008 each. At 50 articles building in 30 seconds per deploy, I would use about 25 build minutes per deploy. Three deploys per week times four weeks: 300 minutes. That is well within the cap.

But the math changes if the site grows to 500 articles and build times approach 2 minutes. At that point, a single deploy costs 2 minutes, and a larger site that needs multiple deploys per week begins eating into the allowance. I know how I work — I deploy small fixes frequently, and I resent any cap that makes me think about whether a typo fix is "worth" a deploy.

Cloudflare Pages has no build-minute pricing at the free tier and no bandwidth cap. The 500-builds-per-month limit is the only constraint, and even at my highest publishing cadence I never approach it. The global edge network routes from 330 cities, and the median TTFB for Pickuma pages is 42 milliseconds worldwide. Vercel's network is comparable in North America and Europe, but Cloudflare's APAC edge presence gives it a measurable advantage for readers in Seoul, Tokyo, and Singapore — a demographic I care about because a meaningful slice of developer tool readers comes from those regions.

I projected costs at three site sizes and the conclusion was unambiguous:

Cloudflare's paid tier at $25/month adds DDoS protection and analytics, which I would activate if the site ever attracted attention from the wrong direction. But Vercel starts at $20 with a build-minute meter running, and Cloudflare starts at $0 with a build-count limit I cannot reasonably hit.

If you are building an interactive SaaS dashboard with server-side rendering and API routes, Vercel is the better choice. Its serverless function platform and Edge Functions are more mature than Cloudflare Workers for SSR workloads. Pickuma is a static blog. The requirements are "serve HTML files fast" and "never wake me up at 3 AM." Cloudflare Pages has failed zero times on "serve HTML files fast" and has never once woken me up.

MDX vs. Headless CMS: Writing Velocity

Every content team I have talked to uses a headless CMS — Sanity, Strapi, Contentful, or their Notion hack. The pitch is always the same: separate content from presentation, give editors a rich text interface, collaborate on drafts.

I rejected every headless CMS option and committed to MDX written directly in VS Code. The decision was not ideological — it was about writing velocity measured in minutes per article.

Here is what I measured, benchmarking myself across 10 articles: writing in a CMS rich-text editor requires constant context switching between the writing surface and the preview. Rich text editors add invisible formatting that breaks when you paste from external sources. Image uploads go through a separate media library with its own UI. Draft collaboration requires a CMS account for every contributor. And the moment you need to do anything the CMS does not support — a custom component, a specific layout, an aside with conditional rendering — you are writing raw HTML in a code block inside a rich text field, and the separation of content and presentation has created more friction than it solved.

MDX in VS Code means I write in the same tool I code in. I see the rendered output instantly with Astro's dev server on the second monitor. Image optimization happens at build time with the Astro Image component — I reference a file path and Astro generates the srcset. Custom components like Callout and Faq are ordinary Astro components I import at the top of the file. The entire workflow is: open a new .mdx file, write frontmatter, write content, save, commit.

The cost is that MDX requires basic comfort with markup. But I am writing for a developer audience about developer tools. The person writing these reviews is the same person reading them. The friction MDX removes — never fighting a WYSIWYG editor's opinion about what my content should look like — outweighs the friction it adds.

Image Optimization: The Numbers That Matter

Image performance is the single largest lever for page speed on a content site, and my approach is boring by design. I use Astro's built-in Image component with Sharp as the optimization engine. Every image in every article is converted to WebP at build time with three sizes: 480px, 960px, and 1440px wide. The component generates an HTML picture element with srcset and sizes attributes, and the browser loads the smallest image that fills the viewport.

I measured the impact on real articles. A review with 8 screenshots at 3840×2160 PNG originals — about 24 MB of raw image data — compresses to 420 KB total across all three sizes in WebP format. The Largest Contentful Paint for that article dropped from 4.8 seconds to 0.9 seconds after optimization. A reader on a 4G connection in Ho Chi Minh City loads the page 5.3 times faster.

The tooling cost is zero additional configuration. Astro's Image component handles the pipeline, Cloudflare's CDN caches the optimized assets at the edge, and I do not think about images again until I add new ones to the article.

One counterintuitive lesson: PNG screenshots of terminal outputs and code editors compress poorly as WebP because the sharp edges and text cause ringing artifacts. For screenshots of code, I found that using the PNG format directly at 2x resolution and letting browsers render them at 1x with CSS gives better visual quality than WebP at the same file size. Your image optimization strategy should be format-aware, not format-zealous.

Tailwind CSS: Why Utility-First Won Over Component Libraries

The styling decision was between Tailwind CSS v4, a component library like shadcn/ui built on Tailwind, and a CSS-in-JS solution like Panda CSS. The decision came down to a single priority: I wanted to open a file, add a class, and see the result immediately with no build step between edit and preview.

Tailwind won because Astro's HMR server reflects class changes in the browser faster than any CSS-in-JS tool I have tested. Change bg-primary to bg-secondary in an MDX file, save, and the change appears in under 100 milliseconds. Panda CSS requires a build step to generate the static CSS, and even with its incremental mode, the feedback loop is 400-600 milliseconds. That difference sounds small but it is the difference between a styling workflow that feels like coding and one that feels like configuring.

I considered shadcn/ui because the component quality is excellent and the copy-paste ownership model aligns with how I think about dependencies. I rejected it because Pickuma does not need interactive components — buttons, dropdowns, dialogs, and form controls. The site's UI is typography, spacing, color, and a handful of Astro components. Adding a component library to style a Callout aside and an FAQ accordion would be bringing a design system to a typography fight.

Tailwind's utility classes also eliminated a class of problems I have seen on every project with custom CSS: unused styles that accumulate because nobody wants to delete a class that might be used somewhere. With Tailwind, the class is either on the element or it is not. There is no styles/legacy/article-callout-v2.css file that nobody remembers creating and nobody is willing to delete.

The Full Cost Breakdown

Total monthly infrastructure cost: $9. That is Buttondown for the newsletter and nothing else. Cloudflare Pages and the CDN are free. Astro is open source. The entire stack runs on Bun, which is free. Every dollar of revenue from the site goes toward making the content better, not keeping the lights on.

I track costs because low overhead is a strategic choice, not an accident. A content site that costs $500 per month to operate needs $500 in monthly revenue before it breaks even. A content site that costs $9 per month can operate at a loss indefinitely while building traffic, which is exactly what Pickuma is doing in its first year. Every tooling decision — Astro over Next.js, Cloudflare over Vercel, MDX over a CMS — was evaluated against a single question: does this choice increase my monthly overhead, and if so, is the benefit worth the cost of needing revenue sooner?

In every case, the cheaper option was also the better option for a static content site. The overhead constraint aligned with the quality constraint, and that alignment is the reason the site can afford to exist while it grows.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.