Rebuild the same? Or merge it all together?

[BZDevelopments]

I don't know if others had this issue, but I got pretty frustrated having to set up the same boilerplate for every next.js project I worked on.

Depending on what I was trying to build, I'd look for an appropriate SaaS, agency, e-commerce, etc. boilerplate, and then I'd spend a lot of time massaging it into something close enough to what I needed.

The frustrating part was that it wasn't really the UI I was after, it was the supporting infrastructure (auth, subscriptions, file storage, email templates, rate limiting, db schemas, etc).

So I built my own solution to this which became LaunchPad, a monorepo next.js project that lets you write code against generic infrastructure while being able to switch out the app type (SaaS, portfolio, ecc) with ease.

The best way to think about it is having a single next.js codebase that has mostly infrastructure code, but allows you to change some configs to target a different set of features.

Some example configs:

// src/user-control/site-config.ts

siteType: "saas"

// "portfolio" | "agency" | "ecommerce" | "content"

I think this is a neat idea because it solves a real problem I was facing with having to set up multiple boilerplates every time I start a new project (and also because it lets me experiment a lot with AI coding).

One of the things I noticed while playing around with AI coding is that it's super easy to get in a situation where the AI starts blowing up your infrastructure code when all you wanted is to add a feature to the application code.

By having these strict boundaries and explicit TS types, I can ask myself (or an AI tool) to "add this feature" while not having to worry that it'll break some auth or db related code.

But that's probably enough intro text for a show and tell post. I've published it on product hunt today, and I'm trying to get some people to take a look at the code and tell me what I did wrong.

In the meantime, the first 15 copies will be discounted to 60$ as I'm collecting feedback/code reviews.

**Project:
https://launchpad-checkout.netlify.app/

Github:
https://github.com/BZDevelopments

Documentation:
https://github.com/BZDevelopments/launchpad-showcase

Simple app:
https://bzdevelopments.github.io/launchpad-showcase/

Product Hunt:
https://www.producthunt.com/@bzdevelopments**

Access to the repo is granted through the GH org invite within 24h.

What I'm curious about is whether or not this is a good approach for other next.js developers.

Do you prefer a single codebase that can be morphed into different applications, or multiple smaller boilerplates for different use cases?

If you take a look and have any thoughts about the architecture, I'd appreciate any feedback, but especially negative feedback since I'm still trying to figure out what's wrong with it

[GitanjaliRodage]

I think you are solving a real pain point, and I would not merge everything into one monorepo without very strict boundaries.

For me, the strongest part of your approach is separating infrastructure from application features. The fact that auth, billing, storage, email, and rate limiting are treated as stable infrastructure while the app type is configurable is a good architectural direction.

I would be careful about one thing though: over time, siteType: "saas" | "portfolio" | ... can become a large conditional matrix where features start depending on each other in unexpected ways.

My preference would be:

• Single infrastructure monorepo
• Feature modules/packages per app type
• Composition over conditionals

Something like:

packages/
  auth
  billing
  storage
  email
apps/
  saas
  portfolio
  ecommerce

Then each app imports only the modules it needs. This keeps the infrastructure reusable while avoiding a growing number of if (siteType === "saas") branches.

Your point about AI coding is actually interesting. Explicit TypeScript boundaries and package-level APIs are probably one of the best ways to reduce accidental changes to critical infrastructure.

So my answer to your question is:

• For solo developers or small teams: your approach is very attractive.
• For larger teams: I would lean toward multiple composed apps sharing common packages rather than a single morphable application.

The idea is good; the long-term maintainability will depend on how aggressively you prevent cross-feature coupling.