DEV Community

theKimLog
theKimLog

Posted on

Building a production ready SaaS starter with Next.js 16: what actually took the longest

When people talk about building a SaaS, the focus is often on the core idea. In reality, most of the time disappears into the same invisible foundation work that never shows up in demos.

Landing pages.
Authentication.
Billing.
Emails.
SEO.
Analytics.
Monitoring.
Testing.

Before any real feature exists, weeks are already gone.

We recently built a production ready SaaS starter on top of Next.js 16, and I want to share what actually took the longest time, what broke in production, and what we would do differently if we started again today.

1. Authentication was not the hard part. The edge cases were

Setting up basic email and OAuth login was easy. The real pain started with everything around it.

Session refresh across server components

Token sync between API routes and middleware

Handling partial OAuth profiles

Account linking edge cases

Deleting users and cascading data safely

The basic tutorial version works in one afternoon. Making it safe in production is what took days.

If you are building your own auth, design the account lifecycle first. Registration is only a small part of it.

2. Subscriptions are easy until invoices and webhooks enter the room

The first Stripe checkout took less than an hour. What followed took a week.

Webhook reliability

Retrying failed payments

Grace periods

Plan downgrades without breaking access

Invoice state matching your internal DB state

The hardest part was not charging users. It was keeping subscription state consistent between Stripe, the database, and the frontend UI.

Strong advice: model your subscription states on paper before writing a single line of billing code.

3. Emails were a silent source of production bugs

Email feels trivial until it breaks user trust.

Verification emails going to spam

Password reset links expiring incorrectly

Edge cases when users change emails mid session

Race conditions between auth and email dispatch

We ended up treating email as a first class production system, not a utility. Logging, retries, and delivery monitoring became mandatory.

4. SEO and metadata took longer than expected

Next.js makes rendering easy. SEO correctness still takes discipline.

Canonical URLs

OG and Twitter cards

Sitemap updates during dynamic routing

Indexing control between preview and production

Structured data validation

None of it is conceptually hard, but missing even one piece quietly hurts distribution for months.

5. Analytics without polluting the app took multiple rewrites

We wanted clean analytics without slowing the app.

Client side tracking without hydration errors

Server side events for billing

Privacy safe defaults

Mapping anonymous to authenticated users cleanly

The mistake we made early was adding analytics after everything else. It should be part of the core architecture from the beginning.

6. Testing was delayed. That was a mistake

E2E tests always come last. That is where the real bugs hide.

The moment we added full Playwright coverage for:

Auth flows

Checkout

Webhooks

Dashboard state

We immediately discovered issues that had been invisible for weeks.

Testing earlier would have saved real production incidents.

What we learned overall

Infrastructure always takes longer than expected.

Most SaaS bugs live in the invisible glue code.

Shipping fast is only possible if foundations are boringly solid.

Starters are not about speed. They are about eliminating entire failure classes.

This experience eventually led us to turn our internal setup into a reusable SaaS starter called Sabo, simply because we never wanted to repeat this whole process again.
You can find it here if you are curious: getsabo

But even if you never use any starter kit, the lessons above apply to every serious SaaS build.

If you are building a SaaS right now

Ask yourself:

Do you fully understand your auth edge cases?

Can your billing system survive failed payments safely?

Are emails observable and debuggable?

Will Google index exactly what you expect?

Do you trust your E2E tests more than your staging environment?

If even one answer is “not really”, that is where most long term pain starts.

If this was useful, I am happy to share deeper writeups on any of these parts in follow up posts. Auth, billing, email delivery, and SEO each deserve their own war stories.

Top comments (0)