Extending SaasForgeKit

This guide shows how to extend SaasForgeKit by building new features as modules.

The best reference in this project is the existing Tasks module, which demonstrates the full path from database schema to UI and tests.

How to think about modules

A typical module in SaasForgeKit includes:

• database migration(s)
• model and factory
• form request validation
• controller actions
• tenant/workspace route registration
• Inertia page(s) in React
• feature tests

If you follow this structure consistently, your custom modules stay easy to maintain and AI tools can extend them reliably.

Tasks module as reference

Use these files as a template:

• Model: app/Models/Task.php
• Controller: app/Http/Controllers/TaskController.php
• Validation:
  • app/Http/Requests/StoreTaskRequest.php
  • app/Http/Requests/UpdateTaskRequest.php
• Routes: routes/tenant.php
• Frontend page: resources/js/pages/tasks/index.tsx
• Tests:
  • tests/Feature/TaskTest.php
  • tests/Feature/MultiDb/TaskTest.php

For a full walkthrough, see:

• Tasks Module Deep Dive

Tenant data design (important)

SaasForgeKit supports both tenancy modes:

• single_db: central DB with tenant isolation columns
• multi_db: tenant-specific databases

For tenant-scoped modules like Tasks:

• central migration exists for single-db mode
• tenant migration exists under database/migrations/tenant for multi-db mode

Follow that same pattern for new tenant modules.

Build your own module: recommended workflow

1. Define your feature scope and data ownership (tenant-scoped vs central).
2. Create migration(s) for both tenancy modes when needed.
3. Create model with proper tenancy behavior.
4. Add factory for tests/seed scenarios.
5. Add Form Request classes for create/update validation.
6. Implement controller methods.
7. Register routes in the correct route file (usually routes/tenant.php for tenant modules).
8. Build Inertia React page(s) under resources/js/pages.
9. Add/extend tests (including multi-db coverage when applicable).
10. Run checks:
    • php artisan test
    • npm run lint
    • npm run types

Conventions to keep

• Reuse existing layout/components before creating new ones.
• Follow existing naming and file placement patterns.
• Prefer small vertical slices (schema + backend + UI + tests) over large refactors.
• Keep module behavior tenancy-safe by default.

Where to connect with other modules

As your module grows, integrate with existing systems when relevant:

• Billing for access gating or plan-based limits
• Workspaces for member-scoped behavior
• Admin modules for operational controls
• Social Auth / User lifecycle where identity context matters