# Strategy: Scaling BukidBountyApp for Multiple Companies

This document outlines the recommended approach for deploying BukidBountyApp across different companies while maintaining efficiency and code quality.

## Comparison of Approaches

| Feature | Option 1: Split Repositories | Option 2: Single Codebase (Multi-Instance) |
| :--- | :--- | :--- |
| **Maintenance** | **High Overhead**. A bug fix in one repo must be manually copied to others. | **Low Overhead**. One fix in the main repo benefits all instances. |
| **Consistency** | **Low**. Repos will drift apart over time, making cross-support difficult. | **High**. All companies run the same version of the platform. |
| **Customization** | **Easy**. Just edit the code for that one company. | **Config-Driven**. Use environment variables or flags to toggle features. |
| **Data Privacy** | **Physical Isolation**. Separate repos usually mean separate DBs. | **Physical Isolation**. Each instance connects to its own database. |
| **Scalability** | **Poor**. Adding a 4th company requires another repo and more maintenance. | **Excellent**. Just add a new deployment in Dokploy. |

---

## Proposed Plan: Single Codebase, Multi-Instance
I propose a **Single Codebase** approach using **Environment-Based Deployments**. This is the standard "Best Practice" for SaaS-like applications.

### 1. Repository Management
*   Keep **one single repository** for all core logic.
*   Use branches (`production`, `staging`) to manage release cycles.
*   Every company pulls from the same codebase.

### 2. Deployment Architecture (Dokploy)
Instead of one Dokploy project, you create multiple deployments pointing to the same repository:
*   **Instance A**: `company-a.bukid.app`
*   **Instance B**: `company-b.bukid.app`
*   **Instance C**: `company-c.bukid.app`

### 3. Environment Variables (.env) for Customization
Use the `.env` file for each instance to differentiate the identity and behavior:
```bash
# Instance A .env
APP_NAME="Company A Bounty"
APP_URL="https://company-a.bukid.app"
PRIMARY_COLOR="#4CAF50"
DB_DATABASE="bukid_company_a"
ENABLE_MODULE_FARMER=true
```

```bash
# Instance B .env
APP_NAME="Company B Marketplace"
APP_URL="https://company-b.bukid.app"
PRIMARY_COLOR="#2196F3"
DB_DATABASE="bukid_company_b"
ENABLE_MODULE_FARMER=false
```

### 4. Code Adjustments for Customization
To make the UI "dynamic" based on the company:
*   **Identity**: Use `{{ config('app.name') }}` in the frontend (passed via Inertia or API).
*   **Theming**: In `app.js` or `index.css`, use CSS variables that can be injected based on environment.
*   **Features**: Wrap specific modules (like Farmer Management) in Feature Flags:
    ```php
    // In a Controller or Vue component
    if (config('features.farmer_module')) {
        // Show farmer features
    }
    ```

### 5. Database Isolation
Since each instance has its own `DB_DATABASE` env variable, the data is physically isolated. This ensures that:
- Company A cannot see Company B's data.
- Migrations are run per instance.
- You can backup/restore Company A without affecting others.

---

## Migration Steps (Advice)

1.  **Audit hardcoded strings**: Scan the code for "BukidBounty" and replace them with `config('app.name')`.
2.  **Move Colors to variables**: If you have hardcoded colors in CSS, move them to `:root` variables in `index.css` and allow them to be overridden or controlled by the app name.
3.  **Setup Dokploy Multi-Project**: Create a second project in Dokploy, use the same SSH key/Repo URL, and configure a second database.
4.  **Feature Toggles**: Create a `config/features.php` file that reads from `env()` to enable/disable specific modules for specific companies.

## Conclusion
**Option 2 (Single Codebase)** is the significantly better long-term choice. It prevents "Maintenance Hell" and ensures that as you improve the app for one company, you are improving it for everyone.