How I Built a Next.js SaaS Boilerplate with Edge SEO Tools
When I first started building SaaS products, I kept running into the same wall during the first two weeks of every project. I would have a great idea, set up a new repository, and immediately get bogged down in infrastructure.
I’d spend days just wiring up NextAuth, configuring Stripe checkout sessions, and setting up webhooks. Then, I’d realize I needed a quick edge function for a side feature—like an SEO analyzer—but splitting the deployment between Vercel and Cloudflare felt like a massive headache.
I was spending more time configuring boilerplate than actually building my product. The initial excitement would fade before I even wrote a single line of core business logic.
So, I decided to build a unified starter kit to solve this once and for all.
The Cost of Boilerplate Friction
In the indie developer world, momentum is everything. When you have an idea, you need to validate it quickly. But the modern web stack is incredibly fragmented.
You might choose Next.js for your frontend and API routes, which is fantastic. But then you need subscription billing, so you pull in Stripe. Then you need a globally distributed, low-latency API for a specific tool, so you look at Cloudflare Workers.
Stitching these together from scratch every time introduces massive context switching. You have to manage different environment variables, different deployment pipelines, and different TypeScript configurations.
The cost of ignoring this friction is high. It leads to abandoned projects, delayed launches, and a lot of duplicated code across your different repositories. If you spend 14 days just setting up the plumbing, you lose the energy required to build the actual house.
A Unified Technical Approach
To solve this, I designed a SaaS starter kit that brings Next.js 14+ (App Router), Stripe, and Cloudflare Workers into a single, cohesive TypeScript-first architecture.
The core philosophy is to let each tool do what it does best. Next.js handles the server-side rendering, state management, and complex database interactions. Cloudflare Workers handle edge-side, globally distributed tasks that require low latency.
Let’s look at how the billing is handled. We use the Next.js App Router to create a secure checkout session. Here is the API route for Stripe checkout:
// Next.js API route for Stripe checkout (App Router) import { NextResponse } from 'next/server'; import Stripe from 'stripe'; const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!); export async function POST(req: Request) { const { priceId, userId } = await req.json(); const session = await stripe.checkout.sessions.create({ mode: 'subscription', payment_method_types: ['card'], line_items: [{ price: priceId, quantity: 1 }], success_url: `${process.env.APP_URL}/dashboard?success=true`, cancel_url: `${process.env.APP_URL}/pricing?cancelled=true`, client_reference_id: userId, }); return NextResponse.json({ url: session.url }); } This keeps the billing logic close to the database and the user session. But for edge tasks, we shift gears.
I wanted to include a built-in SEO checker and landing page analyzer. Fetching and parsing external HTML from a central Node.js server can be slow for users on the other side of the world. By moving this to Cloudflare Workers, the analysis happens at the edge.
Here is the worker script that handles the edge SEO analysis:
// 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' }, }); }, }; Notice how we use regex-based parsing instead of a heavy DOM parser. Since this runs on the edge, keeping the payload lightweight is crucial for maintaining those low latency times.
Practical Results and Trade-offs
Building this unified architecture yielded some great results. The biggest win was the one-click deployment. By standardizing the environment variables and build scripts, deploying the Next.js app to Vercel and the edge workers to Cloudflare Pages became a single command.
What surprised me most was how well the edge workers handled the HTML parsing. I was worried that regex matching on raw HTML strings would be fragile, but for standard SEO checks (like extracting the title, meta description, and counting H1 tags), it has been remarkably reliable and incredibly fast.
If I were to change one thing, it would be how I initially approached webhook handling. I originally tried to route Stripe webhooks through the Cloudflare Workers to keep everything on the edge. However, managing the database ORM and updating user subscription states was much simpler when I kept the webhook handlers inside the Next.js App Router. It’s a good reminder that you don't always need to push everything to the edge just because you can.
Checking Your Own SEO
The edge SEO analyzer I built for the starter kit turned out to be so useful that I packaged it up as a standalone free tool. If you are working on a new project and want to quickly check your landing page's basic SEO health without installing heavy local tools, you can use it here:
It runs entirely on those Cloudflare Workers we just talked about, so you get instant results no matter where you are.
Building a SaaS shouldn't mean starting from scratch every time. I hope sharing this architecture helps you spend less time on boilerplate and more time building something people actually want to use.
Full disclosure: I'm the developer of SaaSLaunch. I built this because I needed it myself.