Designing Removable Modules in a Next.js SaaS Starter

Most SaaS starters say they are modular.

The useful question is: what happens when you remove a module?

If disabling a feature leaves dead navigation links, broken sitemap entries, missing imports, route handlers that still accept requests, or database tables nobody understands, the module was not really modular. It was just grouped in a folder.

Removable modules need boundaries.

Start With User-Facing Surfaces

A module usually appears in more places than its main page.

For example, a waitlist module may include:

• Public route.
• Admin route.
• API route.
• Database table.
• Email template.
• Navbar link.
• Footer link.
• Sitemap entry.
• Feature flag.
• Tests.

If removal only deletes the public page, the product still leaks the feature elsewhere.

Feature Flags Are Not Enough

Feature flags hide behavior at runtime.

They do not remove code.

That distinction matters. Runtime flags are useful for:

• Hiding navigation.
• Returning 404 for disabled routes.
• Removing sitemap entries.
• Preventing API access.
• Running one codebase in multiple modes.

But if a buyer wants a smaller codebase, the setup tool also needs to delete files and update references.

A good starter supports both:

• Feature flags for runtime control.
• Pruning for permanent removal.

Route Groups Help

Next.js App Router route groups are useful for keeping surfaces understandable:

src/app/[locale]/
  (marketing)/
  (auth)/
  (dashboard)/
  admin/

That structure makes it clear which pages are public, protected, authentication-only, or platform admin.

It also lets you reason about SEO. Marketing pages are indexable. Auth, dashboard, and admin pages should be noindex and blocked where appropriate.

Keep Shared Code Honest

The hardest modules to remove are the ones that leak into shared files.

Common leak points:

• navigation.ts.
• sitemap.ts.
• robots.ts.
• proxy.ts.
• Shared schema files.
• Shared validation schemas.
• Shared server actions.
• Shared dashboard layouts.

If a module needs entries in those files, make the entries obvious and grouped. If a setup wizard removes the module, it should know exactly what to prune.

API Routes Need Gates Too

Disabled UI is not security.

If a module has API routes, those routes need their own gates:

• Auth check.
• Permission check.
• Rate limit.
• Feature flag check.
• Input validation.

The proxy can return 404 for disabled feature routes, but route handlers should still follow the same protected pattern. That keeps modules safe when moved, copied, or extended.

Database Tables Should Be Named by Domain

Module data should be easy to identify.

Good table names:

• waitlist_entry.
• feature_request.
• audit_log.
• outgoing_webhook.
• workflow.

Ambiguous table names make removal riskier. If the table name tells you the module, migration work is easier to review.

Tests Should Prove Removal Boundaries

Useful tests include:

• Disabled feature returns 404.
• Disabled feature is absent from sitemap.
• Disabled feature is absent from navigation.
• API route rejects unauthenticated access.
• Module-specific queries still work when enabled.

You do not need massive coverage for every module. You need enough tests to prevent obvious leaks.

Plugins Are for Bigger Boundaries

Not every removable feature should be a plugin.

A simple waitlist page can be a module.

A CRM with pages, routes, hooks, schema, components, AI helpers, and install commands is a better plugin candidate.

Use plugins when the feature has its own lifecycle and customer value. Use modules when the feature is part of the core application shape.

A Practical Removal Checklist

For each module, document:

• What feature flag controls it.
• Which routes it owns.
• Which API routes it owns.
• Which components it owns.
• Which database tables it owns.
• Which navigation entries it adds.
• Which sitemap entries it adds.
• Which tests cover it.
• How to remove it manually.

That list prevents "modular" from becoming marketing language.

The Payoff

Removable modules give buyers confidence.

They can start broad, then strip what they do not need. Or they can keep a larger operational surface without building it themselves.

The codebase stays understandable because module boundaries are explicit.

---

Codapult documents removable features in the modules overview, including routes, dependencies, and manual removal notes.