REST or GraphQL for a New SaaS, and When It Actually Matters

The REST vs GraphQL question comes up in almost every new SaaS project we scope. Founders arrive with a strong opinion pulled from a conference talk. Engineers arrive with a stronger opinion pulled from the last codebase they left. The honest answer is that for most early-stage SaaS, the choice matters less than either camp claims.

This post is the version of the conversation we wish more teams had at the whiteboard — the trade-offs, the failure modes, and a rough decision rule for a small team.

What each one actually is, in one paragraph

REST exposes resources at URLs, and clients grab them one at a time. GraphQL exposes a single endpoint where clients describe the exact shape they want and the server assembles it. Both can be fast, both can be secure, both can be a mess if you skip fundamentals.

When REST is the right default

Nine times out of ten, for a new B2B SaaS with a small team, REST is the boring correct answer. Here's why.

REST maps cleanly onto how HTTP already works. Caching, rate limiting, monitoring, and debugging all use tools you already have. Every engineer on your team has shipped a REST endpoint before. So has every AI coding assistant.

The workflow is short: name your resources, pick your verbs, write the handler. A new engineer can add an endpoint in an hour without reading a spec.

Real scenarios where REST just wins

• Your product's data shape doesn't change often.
• Your clients are mostly your own web and mobile apps.
• You have fewer than four engineers.
• You care about caching, especially at the CDN layer.
• You need webhooks, which REST expresses more naturally.

When GraphQL earns its complexity

GraphQL isn't a mistake. It's a specific tool for a specific problem, and when that problem is yours, it's genuinely nice.

You benefit from GraphQL when clients need wildly different data shapes and you can't keep adding "?include=" query params to REST endpoints forever. That happens most often with public APIs, aggressive mobile apps that care about payload size, and products with rich relational data that clients want to slice differently.

The moments where GraphQL earns its keep

• You're building a developer platform where third parties consume your API.
• You have a mobile app on a slow network that needs surgically shaped payloads.
• Your data has deep, interconnected relationships that clients query variably.
• You have front-end engineers who own their data fetching and hate waiting on backend endpoints.
• You have someone on the team who has run GraphQL in production before.

The last bullet is the quiet one. GraphQL in the wrong hands turns into an N+1 disaster within six months. If nobody on the team has hit that wall before, the learning happens in production.

The failure modes we see

Both stacks fail in predictable ways when a small team picks the wrong one, or picks the right one badly.

REST failures

The most common REST mistake is version sprawl. /v1/users, /v2/users, /v2/users-enhanced. Every time the shape changes, a new URL appears, and old clients keep hitting old versions forever. This is fixable with a real deprecation policy — most teams just don't have one.

The second is over-fetching. A client needs a name and an email, and the endpoint returns a 40-field user object with nested organization data. Fine for a while, painful when the mobile app hits 3G in a subway.

GraphQL failures

The classic is the N+1 query. A client asks for 100 posts, each with their author, and the server issues 101 database queries. Dataloader-style batching solves this, but only if someone remembers to write it. New engineers rarely do.

The second is authorization sprawl. In REST, permissions live at the endpoint. In GraphQL, they live at the field. If your schema has 200 fields, that's 200 authorization checks, and the one you forgot is the one that ships to prod.

The failure that hits both

Under-invested error handling. Both stacks have well-defined error patterns that almost nobody uses correctly. If your API returns a 200 with a JSON body saying "success: false", the pattern you picked doesn't matter — you've abandoned the standard.

What we usually recommend for early-stage SaaS

Our default recommendation for a pre-Series-A SaaS with two to five engineers is REST with a well-thought-out resource model, plus one or two batch endpoints for the front-end use cases that get chatty. This gets you 95% of GraphQL's practical benefit for 20% of the operational cost.

If you know you'll open a public API for developers in the first year, or you have deeply relational data with a heavy mobile app, GraphQL is worth the tax. Not before.

For the underlying stack, our take on Next.js vs TanStack Start covers the framework choice, and Postgres vs MongoDB covers the database side.

What about tRPC, and the rest of the alternatives

If your API only serves your own frontend and both sides are TypeScript, tRPC is the third option worth naming. It gives you end-to-end types without the schema overhead, and for a two-person team shipping a single web app it's often the right choice.

The moment you have a mobile app, a public API, or a partner integration, tRPC becomes awkward. It's a great fit for a small slice of teams and a bad fit for the ones that grow past that slice.

Best practices that apply either way

Whichever API style you pick, the following will save you more time than the choice itself.

• Version explicitly, either in the URL or in a header, from day one.
• Return machine-readable errors with codes, not just human strings.
• Rate limit by user or org, not just IP.
• Log every request with a correlation ID.
• Write a small handful of end-to-end tests that exercise real client patterns.

Getting those five things right does more for your API quality than any framework choice.

Misconceptions worth clearing up

"GraphQL is faster." It isn't inherently. It sends fewer bytes when clients ask for less; it sends more bytes when they ask for more. The database work behind each query is the actual cost.

"REST doesn't scale." It scales to companies with billions of requests per day. What doesn't scale is a REST API without a real design behind it.

"GraphQL removes backend work." It moves it. Now the backend writes resolvers and manages a schema instead of endpoints. Same amount of work, different shape.

Frequently asked questions

The questions that come up most often when we're helping teams pick.

Final call

Pick the option your team can operate, not the one that reads well on a slide. For most early-stage SaaS, that's REST. For a specific subset, GraphQL. For a smaller subset, tRPC. There's no wrong answer that a disciplined team can't ship past, and no right answer that saves an undisciplined one.

If you're mid-scoping and need a sanity check on your API design before you commit, book a call. We'll tell you which one we'd build and why.