DEV Community

Cover image for Stop building your SaaS in React. Seriously.
Sochima Onah
Sochima Onah

Posted on

Stop building your SaaS in React. Seriously.

React is comfortable. I get it.

You know it. Your team knows it. There’s a tutorial for everything.
So why change?
Here’s the problem most people don’t see early:
Your SaaS isn’t just a dashboard.
You’ve got:
a landing page
a pricing page
maybe a blog
And those pages need to load fast.
They need to rank.

Here’s the problem:
// React SPA
// Renders everything in the browser

That means:

  • slower first load
  • weak SEO
  • poor discoverability

Now compare that to:
export async function getServerSideProps() {
// runs on the server before rendering
}

Same React mindset.
But now:

  • pages load fast
  • content is indexable
  • users see something immediately

That’s the difference.

Plain React?
It ships a blank page first… then fills it in.
Google doesn’t love that. Users don’t either.
And you won’t notice;
Until you try to get your first users from search.

Next.js fixes this before it hurts.
SSR. SSG. Out of the box.
Your pages load fast.
They’re indexable.
And your dashboard still works like React.
No hacks. No split setup.

But honestly, the biggest win?
One repo.
API routes. Webhooks. Auth callbacks.
All in one place.
For a small team, that’s not convenience,
That's speed.

To be fair:
If everything is behind a login…
and you already have a solid backend…
React is fine.
Really.

But most early-stage SaaS products aren’t like that.
They’re messy.
Half public. Half private.
Built by 2–4 people moving fast.

And this is where teams mess up.
Not the idea.
The defaults.
They pick tools that feel easy now…
and spend months paying for it later.

Next.js is the boring choice.
And in startups?
Boring usually wins.

Are you using Next.js or React for your SaaS? What pushed your decision? 👇

Top comments (2)

Collapse
 
admin_chainmail_6cfeeb3e6 profile image
Admin Chainmail

We went further than Next.js — we went full vanilla JS with zero frontend framework.

Our desktop email client (Electron app) uses plain HTML + vanilla JavaScript. No React, no Vue, no build step for the frontend. Separate .html and .js files, addEventListener with event delegation, plain fetch() calls to the API.

The result: our entire frontend is comprehensible by AI coding assistants without any framework context. When I say "add a feature to the settings page," the AI reads one HTML file and one JS file. No component tree, no state management library, no hydration mysteries.

Your point about needing both public pages and a dashboard is exactly right. We split it differently: marketing site is static HTML on Cloudflare Pages (instant load, perfect Lighthouse scores), and the app itself is Electron with vanilla JS. Two separate repos, zero shared framework dependencies.

The tradeoff is real — more manual DOM manipulation, more boilerplate for dynamic UI. But for an early-stage product where the priority is shipping fast and not debugging framework upgrade cycles? Zero dependencies means zero framework debt.

The irony is that the "modern" stack advice (use React/Next/whatever) often creates more complexity than the product needs at launch. We shipped a working desktop email client with downloads and Stripe payments running on vanilla JS, and it works great.

Collapse
 
sochicodes profile image
Sochima Onah • Edited

This is a great point and honestly a valid approach, especially for Electron where SEO doesn't exist and the rendering model is completely different.

But I'd say you're actually proving the split architecture argument, not challenging it. Marketing on Cloudflare Pages, app in Electron. That's the same instinct, just without Next.js in the middle.

The AI readability angle is real though. One HTML file, one JS file, no hydration mystery. I get why that's attractive when you're moving fast and leaning on coding assistants.

Where it gets tricky is scale. Vanilla JS is comprehensible until the UI isn't. Manual DOM manipulation compounds. You trade framework debt for complexity debt, it just shows up later and in messier places.

For a desktop email client at early stage? Your call makes complete sense. For a web SaaS with dynamic dashboards and public pages? I'd still bet on boring Next.js over debugging hand-rolled state six months in.