DEV Community: Devits

Hot Take: Next.js Might Not Be the Right Choice for Your Indie SaaS

Devits — Sat, 14 Feb 2026 20:50:43 +0000

Before the pitchforks come out: Next.js is not bad. It's an incredible framework.

But too many solo devs and small teams choose it by default, then fight against it for months.

The caching mental model

Next.js 13+ introduced Server Components, Client Components, streaming, multiple caching layers.

You need a mental flowchart just to understand why your data isn't updating.

I've spent entire afternoons debugging a simple database update not reflecting in the UI. The answer was usually some caching layer I forgot existed.

The deployment reality

Yes, you can self-host Next.js. Technically.

But there's a gap between "it runs" and "it runs optimally." Features like ISR, image optimization, and edge functions work differently outside Vercel.

What I switched to

React Router v7 (formerly Remix). The difference was immediate:

No caching by default. I add it when I need it.
Standard Web APIs. Request, Response, FormData.
Explicit data flow. When something breaks, the stack trace points to my code.

When Next.js makes sense

Content-heavy sites with complex caching needs
Teams with dedicated DevOps
Projects committed to Vercel ecosystem

When it might not

Solo devs who debug everything themselves
MVPs where iteration speed beats optimization
Projects where deployment flexibility matters

The boring choice isn't the wrong choice.

Anyone else made a similar switch? What was your experience?

Why Most SaaS Boilerplates Become Technical Debt Within 6 Months

Devits — Fri, 13 Feb 2026 19:21:47 +0000

I've reviewed dozens of boilerplates over the past year. Bought some, audited others, watched friends struggle with a few more. And I keep seeing the same pattern play out:

Developer buys boilerplate to "save 3 weeks." Developer spends 4 weeks fighting against abstractions they didn't choose.

The root problem isn't code quality. Most boilerplates are well-written. The problem is what I call the abstraction trap.

The Abstraction Trap

Most boilerplates try to be clever. They wrap everything in custom hooks, create proprietary patterns, abstract away the "complexity" of auth and payments.

It looks beautiful on the landing page:

// "Look how simple our auth is!"
const { user, login, logout } = useAuth();

But what happens inside useAuth()? What happens when you need to:

Add a custom claim to your JWT?
Handle a specific OAuth provider edge case?
Debug why sessions expire randomly for some users?

Suddenly you're not debugging your code. You're reverse-engineering someone else's mental model at 2am.

The Whiteboard Test

I now apply a simple test before committing to any boilerplate:

Can I explain every critical flow on a whiteboard without looking at the code?

How does a user sign up, and where does each piece of data go?
What happens when a payment fails mid-checkout?
How do sessions work, and where are they stored?
What's the exact webhook flow for subscription renewals?

If I can't answer these after a day with the codebase, that's not a time-saver. That's future debugging hours in disguise.

What Actually Saves Time

The boilerplates that genuinely reduce development time share common traits:

✅ Reads like a tutorial, not a framework
✅ One obvious way to do each thing
✅ Minimal layers between you and the actual API calls
✅ You can delete 40% on day one and still have something working
✅ Uses boring, well-documented dependencies

The goal isn't to never look at auth code. The goal is to understand it so well that modifications feel safe.

Questions to Ask

Before your next boilerplate purchase:

How many abstraction layers sit between my code and the actual Stripe API call?
If the maintainer disappears, can I still debug billing issues?
Is this stack something I'd choose myself, or am I inheriting preferences?
Can I explain the auth flow to a junior dev in 10 minutes?

The best boilerplate isn't the one with the most features. It's the one you can own completely within a week.

What's your experience? Have you ever regretted a boilerplate choice 3-6 months in?

Stripe vs Mollie: Which One for Your European SaaS?

Devits — Sun, 08 Feb 2026 12:12:09 +0000

If you're building a SaaS in Europe, you've probably defaulted to Stripe. Everyone uses it, right?

But after researching payment options for EU customers, I found out Mollie might be the better choice in some cases.

Stripe

Pros:

Global, works everywhere
Huge documentation
Everyone knows it

Cons:

1.5% + €0.25 for EU cards (higher for non-EU)
Some local payment methods missing
US-first mentality

Mollie

Pros:

Built for Europe
iDEAL, Bancontact, SOFORT, Giropay out of the box
1.8% + €0.25 but often cheaper for local methods
No monthly fees

Cons:

Less known outside EU
Smaller ecosystem

When to use what?

Situation	Best choice
Global audience	Stripe
EU-focused SaaS	Mollie (or both)
Netherlands, Belgium, Germany	Mollie wins
You want one solution worldwide	Stripe

My take

If your customers are mostly European, start with Mollie. You can always add Stripe later.

If you're going global from day one, Stripe is safer.

Or do both. It's more work, but you cover everyone.

What payment processor do you use for your EU SaaS? Curious to hear what others picked.

Why Most SaaS Boilerplates Fail European Developers

Devits — Sat, 07 Feb 2026 13:12:37 +0000

If you're building a SaaS in Europe, you've probably looked at boilerplates. Ship faster, skip the boring setup, focus on your product. Sounds great.

But here's the problem: most boilerplates are built for the US market.

And that creates real issues when you're trying to launch in the EU.

The payment problem

Stripe is everywhere. Almost every boilerplate uses it. But Stripe isn't always the best choice for European businesses.

Some EU countries have low Stripe adoption
Local payment methods (iDEAL in Netherlands, Bancontact in Belgium) aren't supported by default
European customers often prefer local alternatives

Mollie is built for Europe. It supports local payment methods out of the box, has transparent pricing, and is designed with EU businesses in mind.

Yet almost no boilerplate includes Mollie. You're stuck integrating it yourself.

The GDPR gap

US-focused boilerplates treat GDPR as an afterthought. You get a cookie banner and a privacy policy template. That's it.

But being GDPR friendly is more than a banner:

Where is your data stored?
Are you using US-based analytics that transfer data across the Atlantic?
Do your authentication and email providers have DPAs in place?
Can users actually request their data or deletion?

Most boilerplates leave you to figure this out. By the time you realize it, you've already built on top of non-compliant infrastructure.

Documentation matters

This might seem minor, but it's not.

If you're a solo founder in France, Germany, or Spain, reading documentation in English is fine. But when you're debugging at 2am, having docs in your native language saves time and frustration.

Bilingual documentation (English + local language) is rare. But it makes a real difference for non-native speakers.

What to look for

If you're an EU-based developer looking for a boilerplate, here's a checklist:

[ ] Supports Mollie (or other EU payment processors), not just Stripe
[ ] GDPR-friendly defaults (EU data hosting, compliant analytics, proper consent flows)
[ ] Documentation in your language
[ ] Built by someone who understands EU business requirements
[ ] Clear on data residency and third-party processors

The market gap

There's a reason most boilerplates ignore Europe: the US market is bigger and more vocal.

But that's changing. More developers are building from the EU, and they need tools that fit their reality.

If you're building for European customers, start with European infrastructure.

Building a SaaS in Europe? I'd love to hear what challenges you've faced with existing tools. Drop a comment below.

The problem with most SaaS starters (and why we built our own foundation)

Devits — Fri, 06 Feb 2026 12:55:43 +0000

Starting a SaaS project often feels easier than it actually is.

Authentication, routing, payments, database setup — none of these problems are new. Yet they are rebuilt again and again, usually under time pressure, and often without a clear long-term structure.

Over time, we noticed that most early-stage SaaS friction doesn’t come from product ideas.

It comes from weak foundations.

Speed first, clarity later

Many SaaS starters optimize for one thing: speed.

They help you ship a demo quickly, which is useful in the very beginning. But once real constraints appear — billing edge cases, data consistency, compliance, long-term maintenance — the architecture often starts to fight back.

At that point, teams pay the price of decisions that were postponed or hidden behind abstractions.

We wanted to explore a different trade-off.

Reducing cognitive overhead, not just setup time

Instead of asking “How fast can we ship something?”, we asked:

How can we reduce cognitive overhead while keeping the system understandable months later?

That question changed everything.

Rather than stacking features or shortcuts, we focused on:

clear routing and data flows
explicit architectural boundaries
predictable patterns over clever abstractions

The goal wasn’t maximum flexibility.

It was long-term clarity.

Opinionated foundations are unavoidable

A SaaS foundation can’t be neutral.

Avoiding decisions early usually means making harder ones later, when the system is already in motion. Being opinionated upfront helps reduce decision fatigue and keeps the mental model stable as the product grows.

That’s why our approach is intentionally opinionated — not to restrict developers, but to give them a clear baseline they can trust and extend.

Real-world constraints matter early

In practice, production SaaS projects face constraints very quickly: payments, operational requirements, and regulatory considerations are rarely optional.

Treating these as afterthoughts often leads to rewrites or fragile patches. We believe they should be treated as first-class concerns from the start, not bolted on later.

A foundation should disappear

A good foundation shouldn’t be impressive.

If developers spend less time thinking about setup decisions and more time building what actually differentiates their product, then the foundation is doing its job.

That’s the mindset behind why we built our own foundation instead of relying on yet another starter.

We’re sharing this perspective to exchange ideas, not to promote anything.

Curious to hear how others approach early SaaS architecture and where they’ve felt the most friction.