Serverless vs Edge: Architecting a Modern SaaS Boilerplate

When I first started building SaaS products, I kept running into the same architectural bottleneck. I would spend weeks perfecting the frontend, only to hit a wall when deciding how to handle backend API routes. Should I use traditional serverless functions, or push logic to the edge? Every time I started a new project, I had to re-evaluate this trade-off, configure Stripe webhooks, set up NextAuth, and figure out deployment pipelines from scratch. It was exhausting to make these foundational decisions on day one of every new idea. So I decided to build something.

The problem with building SaaS tools today isn't just about writing code; it's about making the right architectural choices early on. When you are deciding between serverless and edge computing, you are actually deciding how your application will scale globally. Traditional serverless functions are fantastic for heavy compute tasks and complex Node.js dependencies. However, they often suffer from cold starts and are typically routed to a single geographic region. This means a user in Tokyo might experience higher latency when hitting an API hosted in Virginia.

On the other hand, edge computing runs your code in data centers all over the world, drastically reducing latency. But it comes with strict constraints: smaller bundle sizes, limited execution time, and sometimes a lack of support for specific Node.js APIs. Ignoring these differences early on can lead to a poor user experience for international customers, or unexpected infrastructure costs as your traffic grows. You end up rewriting core logic when you finally realize your chosen paradigm doesn't fit your actual workload.

To solve this, I took a hybrid approach for my SaaS boilerplate, SaaSLaunch. I wanted to leverage the strengths of both paradigms without forcing developers into a single box. For the core application, I used Next.js 14 with the App Router. This handles the heavy lifting for server-side rendering, complex state management, and integrating the Stripe SDK for subscription billing.

Serverless is the right tool for the billing logic. Stripe webhooks require reliable, persistent execution environments that can handle complex cryptographic verification and database writes without timing out. I paired this with NextAuth.js for OAuth providers, keeping the authentication flows secure and centralized.

But for lightweight, globally distributed tools, edge computing makes much more sense. I integrated Cloudflare Workers to handle edge-side API routes. A perfect example is the built-in SEO checker and landing page analyzer. Instead of routing a user's URL analysis request back to a central server, the edge worker intercepts the request at a node closest to the user.

Here is a look at how the edge worker handles the SEO analysis without needing a heavy DOM parser:

// Cloudflare Worker for edge SEO analysis
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.pathname !== '/api/analyze') {
      return new Response('Not found', { status: 404 });
    }

    const targetUrl = url.searchParams.get('url');
    if (!targetUrl) {
      return new Response(JSON.stringify({ error: 'Missing url' }), {
        status: 400,
        headers: { 'Content-Type': 'application/json' },
      });
    }

    // Fetch target page at the edge (low latency worldwide)
    const response = await fetch(targetUrl, {
      cf: { cacheTtl: 300, cacheEverything: true },
    });
    const html = await response.text();

    // Run SEO checks (regex-based, no DOM needed)
    const title = html.match(/<title[^>]*>([^<]*)<\/title>/i)?.[1] || '';
    const desc = html.match(/<meta[^>]*name=["']description["'][^>]*content=["']([^"']*)["']/i)?.[1] || '';
    const h1Count = (html.match(/<h1[ >]/gi) || []).length;

    return new Response(JSON.stringify({ title, desc, h1Count }), {
      headers: { 'Content-Type': 'application/json' },
    });
  },
};

By using Cloudflare Workers, we can fetch the target HTML and run lightweight regex checks directly at the edge. The cf object allows us to utilize Cloudflare's cache features, keeping execution fast. This avoids the overhead of spinning up a headless browser or loading a massive HTML parsing library, keeping the worker well within the strict execution time limits of edge environments.

What worked really well with this hybrid setup was the separation of concerns. Keeping the Stripe checkout and NextAuth logic on standard serverless routes meant I didn't have to fight against edge environment limitations for complex database transactions. Meanwhile, pushing the SEO analyzer to the edge resulted in noticeably faster response times for users outside the primary deployment region.

What surprised me was how easy it was to maintain type safety across both environments by keeping the project strictly TypeScript-first. Sharing types between the Next.js frontend and the Cloudflare Workers backend made the developer experience much smoother. If I were to change anything, I would probably create an even more abstracted routing layer in the boilerplate so developers don't have to manually configure the deployment boundaries between Vercel and Cloudflare Pages. The one-click deployment works well now, but abstracting the edge routing further would save even more time.

If you want to see this edge architecture in action, I've deployed the SEO analyzer as a free tool. You can test your own landing pages and see how edge computing handles the analysis in real time, checking your titles, meta descriptions, and header counts instantly.

You can try the SEO Checker here: https://saaslaunch.dev/free-tools/seo-checker

---

Full disclosure: I'm the developer of SaaSLaunch. I built this because I needed it myself.