Module Architecture

Design Principles

Every feature in Codapult is packaged as a self-contained module with its own directories, routes, components, and database tables. Modules follow three rules:

1. Bounded — each module has documented directories and dependencies, so its removal scope is visible before you change the project.
2. Core-dependent only — modules depend on the Core layer (Auth, Database, Rate Limiting, Validation), not on each other, unless explicitly noted.
3. CLI-removable where mapped — the interactive setup wizard can remove supported module groups automatically; shared schema and dependencies still require review.

Module Map

The Removable column describes the documented manual removal scope. The setup wizard covers a smaller set of explicit groups: Authentication & Dashboard, AI Chat, RAG Pipeline, AI Agents, AI Batch, AI Playground, Blog, Teams, Waitlist, GraphQL API, Enterprise SSO, API Docs, Documentation, Changelog, A/B Testing, Feature Requests, Compare, Stripe Connect, Event Store, OpenTelemetry, Drip Campaigns, Onboarding Tours, Workflow Automation, Referral Program, Built-in Analytics, Outgoing Webhooks, Audit Log, Scheduled Reports, White-label Branding, and Two-factor Authentication (UI). Capabilities such as Billing, Email, Notifications, File Uploads, and SEO require manual removal or configuration review.

Removal vs. Disabling: Two Different Operations

Codapult has two separate ways to exclude a module from your product. Understanding the difference before setup matters.

Removing a module (CLI or manual): The module's mapped code is deleted from your repository — files, routes, and components covered by the removal scope. Shared schema, imports, and dependencies must be reviewed when they are used by more than one module. Use this path when the capability is outside your product scope; the generated diff gives you a clear review point before you continue. If the product expands later, restore the capability by merging the relevant source from the template and reviewing the resulting diff.

Disabling a module (env var, reversible): If a module is present in the codebase but you are not ready to use it, you can hide it via an environment variable. The code stays in the repo; the feature is invisible to users. Flip the variable to re-enable it at any time, with no code changes.

Practical rule: Remove modules you are confident are outside your product's scope. Keep modules you may introduce later and disable them via env var until the product is ready for them. This keeps the path reversible while you shape the first release.

How to Remove a Module

CLI Wizard (Recommended)

Run the interactive setup wizard and deselect the modules you don't need:

npx @codapult/cli setup

The wizard deletes mapped files and applies supported prune markers. Review shared imports, schema tables, environment variables, and dependencies before generating migrations or building the project.

Review the generated change. The wizard deletes mapped files and applies prune markers — it does not just hide the feature. If a capability may return later, leave it in and turn it off with the matching ENABLE_* environment variable instead (see the Module Map below or Environment Variables).

Manual Removal

For finer control, remove a module by hand:

1. Delete the module's directories (see the table above).
2. Remove all imports referencing the deleted module.
3. Remove database tables from src/lib/db/schema.ts and regenerate migrations.
4. Remove navigation links from src/config/navigation.ts, Sidebar.tsx, admin layout, and marketing navbar.
5. Uninstall npm dependencies unique to the module.
6. Remove environment variables from .env.example.

Example: Removing the AI Core

# Delete files
rm -rf src/app/\\[locale\\]/\(protected\)/\(dashboard\)/dashboard/ai/chat
rm -rf src/app/api/ai/chat
rm -rf src/components/ai

# Remove AI navigation items from Sidebar.tsx
# Edit src/components/dashboard/sidebar/Sidebar.tsx

# Uninstall dependencies (if not used elsewhere)
pnpm remove @ai-sdk/openai @ai-sdk/anthropic ai @ai-sdk/react

# Remove env vars from .env.example:
# OPENAI_API_KEY, ANTHROPIC_API_KEY, EMBEDDING_PROVIDER,
# VECTOR_STORE_PROVIDER, OLLAMA_BASE_URL, OLLAMA_EMBEDDING_MODEL

Example: Removing Teams

# Delete files
rm -rf src/app/\\[locale\\]/\(dashboard\)/dashboard/teams
rm -rf src/app/\\[locale\\]/invite
rm src/components/dashboard/TeamSwitcher.tsx
rm src/components/dashboard/TeamSettings.tsx
rm src/components/dashboard/AcceptInvitationButton.tsx
rm src/lib/db/organizations.ts
rm src/lib/actions/organizations.ts

# Remove organization tables from src/lib/db/schema.ts:
# organization, organization_member, organization_invitation

# Remove TeamSwitcher from Sidebar.tsx

# Regenerate migrations
pnpm run db:generate

Dependency Boundaries

Modules form a layered dependency graph. The Core layer is required; everything above it is optional, with removal scope and dependencies documented per module.

┌───────────────────────────────────────────────┐
│                 Core Layer                    │
│  (Auth, Database, Rate Limiting, Validation)  │
└─────────────────────┬─────────────────────────┘
                      │
         ┌────────────┼────────────┐
         │            │            │
    ┌────▼────┐  ┌────▼────┐  ┌────▼────┐
    │ Billing │  │  Teams  │  │  Admin  │
    └─────────┘  └─────────┘  └─────────┘
         │            │            │
    ┌────▼────┐  ┌────▼────┐  ┌────▼────┐
    │ Usage   │  │  RBAC   │  │ Feature │
    │ Credits │  │         │  │  Flags  │
    └─────────┘  └─────────┘  └─────────┘

Most modules build on the Core layer, and some also depend on other modules. The Dependencies column is authoritative; for example, SCIM Provisioning depends on Teams and Chat Memory depends on AI Chat.