Why we build on Cloudflare: a boutique studio's infrastructure stack explained

Most boutique software studios pick a tech stack by accident — whatever the founder learned first, whatever the latest big project demanded. We did that for years.

In 2024 we made the choice deliberately. Every active production system we run sits on Cloudflare’s platform. This post explains why, what it costs, and where it doesn’t fit.

The stack, in one paragraph

For client projects in 2026 we use: Astro for the marketing/content layer, React or vanilla TypeScript for application UI, Cloudflare Workers for serverless compute, D1 (SQLite) for relational data, KV for caching, R2 for object storage, and Workers Analytics + Sentry for observability. AI work calls OpenAI, Anthropic, and Google APIs from the Worker layer. Authentication is Auth0 or Clerk depending on requirements. Email is Resend or Postmark.

Everything but the AI providers, Auth0/Clerk, and the email senders is Cloudflare. That’s intentional.

Why Cloudflare won

Three reasons, in order of importance:

1. Pricing that scales gently

Most modern cloud platforms have a pricing model designed to extract maximum revenue from successful applications. Bills can spike 10x overnight if a single config is wrong. AWS is notorious for this; even Vercel can produce unpleasant surprises at scale.

Cloudflare’s pricing is gentle and predictable. Free tier is generous. Paid tier scales linearly. We have client production systems that handle real traffic for $30–$80/month total infrastructure. The same workload on AWS would be $300–$800/month with the same engineering effort.

For a boutique studio handing off self-supporting production systems to small business clients, this matters enormously. We don’t want our clients getting a $1,200 bill in month 9 because traffic doubled.

2. The integrated suite

Cloudflare ships compute, database, object storage, CDN, edge caching, queue, cron, and AI all on one account with one billing relationship and consistent APIs. Want to write to a database from a Worker? Six lines. Want to read from object storage? Five lines. Want to schedule a daily job? Update wrangler.toml.

Compare to the AWS equivalent — compute is Lambda, database is RDS or DynamoDB, storage is S3, CDN is CloudFront, queue is SQS, cron is EventBridge, AI is Bedrock — and each has its own IAM model, billing, and API surface. The integration work alone is half the project.

For a 2-person studio that needs to move fast, fewer integration seams is the actual product.

3. Edge-by-default

Workers run at over 300 edge locations globally. A request from a customer in Sacramento hits the nearest Cloudflare PoP (usually in the Bay Area), executes there, and returns. Cold-start latency is measured in single-digit milliseconds.

The traditional model — origin server in a single region — adds 50–200ms of round-trip time for users far from that region. Multiply that across a few API calls in a single page load and you’ve added a noticeable feeling of slowness.

This used to require expensive CDN configuration. With Workers it’s the default.

The trade-offs we accept

Honest trade-offs. Cloudflare isn’t pareto-optimal for everything.

No traditional Postgres. D1 is SQLite, which is excellent but isn’t Postgres. If your application genuinely needs Postgres-specific features (advanced JSON indexing, full-text search beyond FTS5, complex CTEs, certain replication topologies), you’ll want Neon, Supabase, or a managed Postgres elsewhere. We use Hyperdrive to connect to external Postgres when this is needed.

Limited GPU/heavy ML. If you need to run your own ML inference on big models, Cloudflare’s AI Workers tier helps but doesn’t cover everything. Heavy custom ML still wants AWS Sagemaker, GCP Vertex, or dedicated GPU hosts.

Compliance edge cases. Some federal and healthcare workloads still require specific vendor certifications (FedRAMP High, certain HIPAA configurations) that are more mature on AWS or Azure. For 90% of SMB work, Cloudflare’s enterprise compliance is more than sufficient.

Smaller ecosystem. AWS has 30,000 community blog posts on every conceivable topic. Cloudflare has 3,000. Sometimes you have to read source code. Workable, but real.

What we’d use instead, by workload

For specific workloads where Cloudflare isn’t the right fit:

• Heavy ML model training: AWS Sagemaker or RunPod.
• Real-time video processing: AWS MediaLive or Mux.
• Complex data warehousing: Snowflake or BigQuery.
• Large Postgres workloads: Neon or Supabase, connected via Hyperdrive.
• Specific compliance regimes: AWS GovCloud or Azure Government.

For everything else — typical web apps, customer SaaS, internal tools, content sites, e-commerce, document-processing AI workflows — Cloudflare is what we reach for.

A representative cost breakdown

A real client production system we run, anonymized:

• Traffic: ~50,000 page views/month, ~200,000 API calls/month.
• Data: ~3 GB in D1 across ~80 tables, ~12 GB in R2.
• AI: ~$80/month in OpenAI calls for document extraction.
• Other: Sentry $26/month, Resend $20/month, Cloudflare Workers Paid $5/month, D1 + R2 + KV at usage tier ~$8/month.

Total infrastructure: ~$140/month.

The equivalent on AWS, configured for similar performance and availability, would be in the $400–$900/month range and require 2-3x the engineering time to maintain.

Why this matters for clients

For our clients — small businesses in Sacramento, Roseville, Auburn, and beyond — Cloudflare’s economics mean their custom software has a low ongoing burden. The system can sit and run for years at low cost without needing a quarterly cloud-architecture review.

That’s the actual product. A small business doesn’t want to think about infrastructure. They want software that works, costs predictable money, and doesn’t surprise them. Cloudflare delivers that more reliably than any other platform we’ve used.

When we’d recommend against it

If your in-house team is deeply AWS-native and has no appetite to learn a new platform, stay on AWS. The cognitive cost of platform migration usually outweighs the infrastructure savings.

If you’re building a product that depends on a specific AWS-only service (deep Sagemaker integration, MediaLive, IoT Core), don’t fight it.

If your project’s success depends on hiring engineers who happen to know your stack, AWS and Vercel have larger talent pools than Cloudflare.

For everyone else — and that’s most boutique software work — Cloudflare is what we use and what we recommend.

If you want to talk through what stack makes sense for your specific project, we’re happy to. We’re always glad to recommend you stay on what you’re already running if the math doesn’t justify a move.