Why I built Groundbase on Cloudflare Workers instead of Vercel

When you start a new SaaS in 2026 the default stack is some version of Next.js + Vercel + Postgres + Stripe. Every starter kit assumes it. Every Twitter thread recommends it. Every tutorial uses it.

I picked Cloudflare Workers + Turso + Stripe instead. Not because Vercel is bad — it's a great product — but because the constraints I cared about pointed elsewhere. Here's the honest breakdown of why, and when it does and doesn't make sense.

What Vercel does well

Want to be fair upfront. Vercel is the default for good reasons:

• The DX is unmatched. git push deploys. Preview URLs per PR. Built-in analytics. The integration with Next.js is seamless because they make both.
• The Next.js ecosystem is huge. Almost every modern React library targets Next.js. Almost every starter kit assumes Next.js + Vercel. You'll never run out of examples.
• Serverless functions just work. Edge functions, server components, ISR, on-demand revalidation — Vercel hides a ton of complexity behind clean APIs.
• Postgres is well-supported. Through Neon, Supabase, or their own offering. Battle-tested database tooling, mature ORMs.
• For most indie SaaS projects, it's the right call. Especially if you're shipping a v1, raising money, or optimizing for speed-to-market.

If you're starting fresh and aren't sure what stack to pick, defaulting to Next.js + Vercel + Postgres is a defensible move. You'll never get fired for it.

Why I picked Cloudflare Workers anyway

A handful of reasons that matter for Groundbase specifically, listed in order of how much they mattered:

1. The cost curve is fundamentally different

Vercel's free tier looks generous until you start hitting actual traffic. Bandwidth ($$ per GB after 100GB), function invocations, image optimizations — the meter spins on multiple axes. At indie SaaS scale (low hundreds of users), you're usually fine on free. At scale (thousands of users), the Vercel bill becomes a real line item — and the only way to bring it down is to leave.

Cloudflare Workers pricing is simpler: free tier covers 100,000 requests/day; paid plan is $20/month flat for 10 million requests included. No surprise bandwidth charges. No image optimization meter. No "you exceeded build minutes." The cost curve stays flat for far longer.

For a $9/month product with thin margins, this matters. The math on a $200/month Vercel bill against a customer base paying $9/month each is just bad.

2. Truly global by default

Vercel's edge functions are good but the cold-start behavior + cross-region latency can be uneven. Cloudflare Workers run in 300+ data centers and have effectively zero cold starts because they use V8 isolates instead of containers. A request from Buenos Aires gets served from a Buenos Aires data center, not "us-east-1 fronted by a CDN."

For a CRM where Argentine users, German users, and Australian users all hit the same backend, this matters. The product feels equally fast everywhere.

3. The data layer is built for the edge

Turso (libSQL) is what I use for the database. It's a SQLite fork that ships with native replication to the edge — your data lives close to wherever the Worker runs. Postgres on Neon or Supabase is great but it's still a centralized database that you're routing edge requests to. The latency math is worse.

There's a deeper philosophical thing too: SQLite at the edge is a fundamentally different architecture than "Postgres + replicas." It treats the database as something that should live as close to the user as the compute does. For a CRM with global users, this is the right shape.

4. The ecosystem is small but the primitives are good

Workers has a smaller ecosystem than Next.js, which sounds like a disadvantage. In practice, the primitives are good enough that you don't need much else:

• KV (key-value store)
• D1 (SQLite, similar to Turso)
• R2 (S3-compatible blob storage, no egress fees — huge if you store anything)
• Durable Objects (for stateful per-user logic)
• Queues
• Cron triggers
• WebSockets

For Groundbase, I use Workers + Turso + Stripe + Resend, full stop. No ORM, no framework, just TypeScript + the Workers runtime. The codebase is small and easy to reason about.

5. No-egress R2 storage

Tangential but real. Cloudflare R2 (their S3 alternative) has zero egress fees. If your product stores any kind of media (call recordings, voicemail audio, uploads), egress fees on S3 are a huge hidden cost. R2 eliminates it. Once you start storing real volume, this is a meaningful difference.

What Cloudflare Workers doesn't do well

Want to be honest about the tradeoffs:

• The framework story is weaker. No Next.js equivalent for Workers. You write the HTTP routing yourself, or use lightweight tools like Hono. For a backend-only Worker (like Groundbase's auth + Stripe handler), this is fine. For a full-stack app where you want server components and ISR, you're rebuilding things Next.js gives you for free.
• Long-running compute is gated. CPU per request is limited (50ms on free, more on paid). Anything that needs minutes of compute time — heavy AI inference, large file processing, video encoding — doesn't fit Workers cleanly.
• Smaller developer community. Less Stack Overflow, fewer tutorials, fewer hire-able developers familiar with the stack. If you're building a team, this matters. If you're solo, less so.
• Less mature observability. Cloudflare's logging + analytics for Workers are decent but not as polished as Vercel's dashboards or Datadog. You'll find yourself using wrangler tail more than a fancy log explorer.

If your product needs heavy compute, deep framework integration, or you're hiring a team that already knows Next.js — Workers will frustrate you. Vercel will fit your workflow better.

When Cloudflare Workers is the right call

Based on my experience building Groundbase, I'd recommend Workers over Vercel when:

• You're building a backend-heavy product (APIs, webhooks, integrations)
• Cost predictability matters more than feature breadth (especially at scale)
• Your users are globally distributed
• You're storing media and don't want to pay egress fees forever
• You're a solo dev who wants a small, comprehensible runtime instead of a sprawling framework
• You value cold-start-free edge compute (real-time apps, low-latency interactions)

I'd recommend Vercel over Workers when:

• You're building a Next.js full-stack app and want the framework to do the heavy lifting
• You need rich server components, ISR, or other Next.js-specific features
• Your team already knows Next.js and you don't want to retrain
• You need heavy compute time per request (AI inference, video processing)
• You're shipping a v1 fast and don't want to fight with primitives

The honest meta-point

Most indie SaaS founders default to Next.js + Vercel because that's what every starter kit assumes. That's a fine default but it's not a free choice — you inherit the cost curve, the framework opinions, the deployment model. For some products that's exactly what you want. For others (mine), the constraints I cared about pushed me elsewhere.

The most useful thing I can offer here isn't "switch to Workers" — it's "actually think about your constraints before defaulting to the stack everyone else is using." Latency, cost, compute model, global distribution, ecosystem maturity — these are real tradeoffs. The right stack depends on which ones matter for what you're building.

For Groundbase, Workers was clearly right. For other products it's clearly wrong. The mistake isn't picking either one — it's picking by default instead of by reasoning.