Next.js development agency: how to choose one for SaaS

Hiring a Next.js development agency for a SaaS product is not the same decision as hiring one for a marketing site. A SaaS has accounts, payments, permissions and customer data. Mistakes in those layers are expensive to reverse and invisible in a demo.

This guide is for founders, CTOs and executives who are about to compare proposals. It does not rank agencies. We are one of the agencies you could pick, so we give you criteria and the evidence to ask for, and you can apply the same test to us.

The short version: a Next.js SaaS is mostly back-end work behind a fast front end, the architecture choices made before the quote set most of the cost, and the best signal of a good agency is proof you can inspect, not a portfolio of screenshots.

What a Next.js SaaS build includes#

When someone says "build us a SaaS", the visible part is the dashboard. The work sits underneath. Next.js for SaaS is a strong fit because one codebase covers the interface, server rendering and the API layer, but each of the four blocks below still needs explicit decisions. If a proposal lists screens and not these blocks, it is pricing the wrong thing.

Auth and roles#

Authentication is more than a login form. You need sign-up, email verification, password reset, single sign-on if you sell to larger companies, and a role model (owner, admin, member) enforced on the server, not only hidden in the interface. Decide early whether to use a managed identity provider or a library inside the app. Both work. Switching later means migrating every user.

Billing and subscriptions#

Billing is where SaaS estimates most often shrink. A checkout page is the easy part. The real work is the subscription lifecycle: trials, upgrades with proration, failed payments, cancellations, invoices and tax. The Stripe Billing documentation describes these states, and your app has to mirror them through webhooks so access follows payment status. Ask how the agency keeps your database and the payment provider in sync when a webhook arrives twice or out of order.

Multi-tenancy and data isolation#

Multi-tenancy means many customer organizations share one application without seeing each other's data. The common models are a shared database with a tenant identifier on every row, a schema per tenant, or a database per tenant. The first is the cheapest to run and the easiest to build, and it fails badly if a single query forgets the tenant filter. A good agency enforces isolation in one place, such as database row-level security or a single data access layer, rather than trusting every developer to remember.

Dashboards and APIs#

Dashboards need filtering, pagination, exports and empty states, which take longer than the charts themselves. The API layer matters because your customers will eventually ask for integrations. Plan for authenticated endpoints, rate limits, versioning and outbound webhooks. If AI features are on your roadmap, this is the layer they plug into, as we describe in AI integration in SaaS platforms.

Architecture decisions to settle before quoting#

An agency that quotes before these decisions are made is guessing. A good one raises them in the first call, because each one changes the price. The Next.js documentation is the reference for the framework side. You do not need to read it, but you should hear your agency use its terms precisely.

Request path

1. 01BrowserUser opens a page or submits a form
2. 02Server componentsRender data on the server
3. 03Route handlersHandle mutations and webhooks
4. 04Tenant checkScope every query to one tenant
5. 05Tenant-aware databaseData stays isolated per customer
6. 06Stripe and emailBilling and transactional messages

Request path of a Next.js SaaS from the browser through server components and route handlers to a tenant-aware database and external services

App Router and server components#

The App Router is the current routing model in Next.js. It renders components on the server by default, which keeps data fetching close to the database and sends less JavaScript to the browser. Interactive parts, such as forms and charts, are marked as client components. Ask which parts of your product will be which. An agency that marks everything as a client component is building a slow single-page app inside a framework designed to avoid that.

Route handlers or a separate backend#

Next.js route handlers and server actions can serve as your API. For many early SaaS products that is enough: one repository, one deployment, one team. A separate backend makes sense when you have long-running jobs, several clients (web, mobile, partners) sharing one API, or a team that already works in another language. Neither is wrong. What matters is that the agency can explain the trade-off for your case and what moving later would cost.

Webhooks show the difference between a demo and a product. This route handler verifies a Stripe signature before it trusts the event:

// app/api/stripe/webhook/route.ts
import Stripe from "stripe";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(request: Request) {
  const signature = request.headers.get("stripe-signature");
  if (!signature) {
    return new Response("Missing signature", { status: 400 });
  }

  // Read the raw body: verification fails on re-serialized JSON
  const body = await request.text();

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    );
  } catch {
    return new Response("Invalid signature", { status: 400 });
  }

  switch (event.type) {
    case "customer.subscription.updated":
    case "customer.subscription.deleted":
      // Update the tenant's plan in the database
      break;
    case "invoice.payment_failed":
      // Flag the account and start the dunning flow
      break;
  }

  return new Response(null, { status: 200 });
}

Three details matter here: the raw body is read as text, the signature is verified before anything else, and the handler answers quickly. A production version also stores the event id so a repeated delivery changes nothing.

Database, hosting and background jobs#

Most SaaS products on Next.js use PostgreSQL, which handles relational data, tenant isolation and reporting well. Hosting is a second decision. A managed platform built around Next.js is the fastest start, while containers on a cloud provider give more control over cost and region. Background work, such as sending invoices, importing files or calling AI models, should not run inside a web request. Ask where queues and scheduled jobs live, and how failed jobs are retried.

When Next.js is the wrong choice#

A good agency will talk you out of Next.js when it does not fit. A framework is a means, and some parts of a SaaS business are better served elsewhere. Our comparison of Next.js, Astro and Remix shows where each framework earns its place.

Content sites and marketing pages#

If the main job of a site is publishing pages that marketers edit, WordPress or Webflow ships faster and costs less to run. Editors get a visual interface, previews, forms and SEO tooling without a developer. In Next.js you would build or buy all of that, and every copy change becomes a pull request or a headless CMS integration. That is a legitimate choice for a large team, but it is rarely the cheapest one.

Next.js is also the wrong choice for a prototype you expect to throw away. A short validation round with a no-code or AI-assisted prototype, as in building micro-SaaS with AI agents, can save months before you commission a full build.

A split setup: marketing site plus app#

Many SaaS companies end up with two systems: a marketing site on WordPress or Webflow at the root domain, and the product in Next.js on a subdomain. Marketing keeps full control of pages, the engineering team keeps the product, and each deploys on its own schedule. The cost is a shared design system and consistent analytics across both. Agree on those at the start and the split works well.

How to evaluate a Next.js development agency#

Portfolios are curated. Evidence is not. The goal of vetting is to move from claims to artifacts you can inspect. For the questions that apply to any web agency, see questions to ask a web development agency. The criteria below are specific to SaaS.

Agency vetting funnel

1. 01Shortlist by SaaS workKeep agencies with shipped SaaS products
2. 02Technical reviewInspect code, ownership, tests and CI
3. 03Paid discoveryTest the working relationship on real scope
4. 04Scoped proposalFixed scope, milestones and handover terms

Four-stage vetting funnel for a Next.js agency, with ownership and test checks at the technical review stage

Past SaaS work you can inspect#

Ask for a live product you can sign into, not a case study PDF. Look for things a screenshot cannot show: how it behaves with an empty account, an expired subscription, a user without permission. Then ask which parts the agency built, since some agencies list work done by a client's in-house team. A reference call with a previous founder, focused on what went wrong and how it was handled, tells you more than a testimonial.

Code ownership and repository access#

The contract should say you own the code, and the practice should match it. Ask whether the work happens in a repository under your organization from day one, using your cloud and payment accounts, not the agency's. Also check the license of any internal starter kit the agency brings: you need the right to run, modify and hand over everything it contains.

Testing, CI/CD and security practice#

Ask what is tested and how it runs. A SaaS needs automated tests on the money and permission paths at minimum: billing state changes, role checks and tenant isolation. Every pull request should run tests and type checks in a CI pipeline, and deployments should be automatic with a rollback path.

For security, ask which controls the agency works from. The OWASP Application Security Verification Standard is a practical checklist. An agency that knows it will talk about authentication, session handling, access control and input validation without being prompted.

Post-launch support and handover#

A SaaS is not finished at launch. Ask who monitors errors, who responds to an incident and within what time, and who applies dependency and framework updates. Next.js ships major versions regularly, and an unmaintained app drifts. Ask for documentation, a runbook and a handover session, so you could move to another team without a rewrite.

Use this list as a scoring sheet during vetting:

• Sign into a live SaaS the agency built and test its edge cases
• Review a real, anonymized pull request and its review comments
• Confirm the repository, cloud and payment accounts are yours from day one
• Ask for the test strategy on billing, roles and tenant isolation
• See the CI/CD pipeline, including staging and rollback
• Ask how they handle a Stripe webhook that arrives twice
• Ask which OWASP ASVS controls they apply and how they verify them
• Ask who handles incidents and updates after launch, and under what terms

An agency does not have to pass all eight, but it should answer each one with an artifact rather than an assurance.

Fixed project or monthly retainer#

The engagement model should follow how fast your product will change. Our engagements page describes the formats we offer: one-off projects, a monthly Retainer and a monthly Care plan. The trade-offs below apply whichever agency you choose.

When a fixed scope works#

A fixed project fits when scope is clear, the product is narrow and you can write acceptance criteria. Examples are a billing integration, a migration or an internal portal with defined roles. You get a predictable budget and a clear end date. The price is rigidity: every change is renegotiated, and discovery you skipped turns into disputes.

When a retainer fits better#

A SaaS that is still finding its market changes weekly. A monthly retainer buys a team's capacity rather than a list of features, so you can reprioritize without a change order. It fits best after launch, when customer feedback decides the roadmap. It needs a founder who can prioritize, because capacity without direction is only a bill.

A hybrid: scoped launch, then retainer#

Our preferred shape for a new product is a hybrid. Start with a paid discovery that produces architecture decisions, a backlog and an estimate with its assumptions. Fix the scope of the first release, then move to a retainer for everything after it. You keep a clear first deadline and the freedom to learn from real users.

Scope drivers explain price better than screens do. For example, a SaaS with email login, one plan and one workspace per account is a very different build from one with single sign-on, three plans with usage-based pricing and a public API, even if both have ten screens. This is an illustration, not a price list. If an estimate does not mention these drivers, ask why.

Red flags in a Next.js development agency proposal#

A proposal is the first deliverable. Read it the way you would read the product: for what is missing, not only for what is there.

Estimates with no assumptions#

A single number with no assumptions is a guess presented as a quote. A credible estimate states what it includes, what it excludes and what would change it: number of roles, plans, integrations and environments. Be careful with a price far below the others. It usually means billing, tenancy or tests are missing, and they will appear later as change requests.

Missing non-functional work#

Look for line items on the work nobody demos: authentication edge cases, billing webhooks, tenant isolation tests, error monitoring, backups, a staging environment, accessibility and a security review. If the proposal lists only pages and features, ask where those items are.

Lock-in and unclear ownership#

Watch for code held in the agency's repository, hosting on the agency's accounts, internal frameworks you cannot hire for, and an exit clause that charges fees to leave. Also check who does the work. Senior people in the sales call and a different team in the build is common. Ask for named people and their roles in writing.

Where to start with a Next.js development agency#

Start with a one-page brief: who the customers are, the one workflow the product must do well, the plans you will sell, the integrations you need and your constraints on budget, date and compliance. Shortlist two or three agencies, run the checks above, and pay the finalist for a short discovery before committing to a full build. A paid discovery costs little next to a wrong architecture.

If you want our view, our custom apps service covers Next.js products from discovery to long-term maintenance. Bring us the brief and we will tell you whether Next.js fits, even if the honest answer is WordPress or Webflow.

Frequently asked questions#