> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qa.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Projects

> Organize your testing infrastructure with projects, applications, and environments

QA.tech uses a hierarchical structure of **projects**, **applications**, and **environments** to organize your testing infrastructure. Understanding when to use each level helps you maximize test reuse and build efficient CI/CD workflows.

## Understanding the Hierarchy

```
Organizations (billing, team management)
└── Projects (team access, complete isolation)
    └── Applications (distinct apps with own test suites)
        └── Environments (same app, different deployments)
```

### Organizations

**Organizations** are the top-level container for your company or team. They contain multiple projects and manage billing and team access at the organization level.

### Projects

**Projects** are containers for team access and complete isolation between product lines.

Use separate projects only when there are no possible shared user flows between the things being tested. For example:

* Completely separate product lines with no shared functionality
* Different teams that need complete isolation
* A consultant working with completely separate clients

### Applications & Environments

**Applications** represent distinct apps or services with their own test suites. **Environments** represent different deployments of the same application (e.g., staging, production, PR previews).

See [Applications & Environments](/core-concepts/applications-and-environments) for a full explanation of when to use each.

## Example: Full Hierarchy

**Organization: Pet Solutions Ltd**

```
Project: Veterinary App
├── Applications:
│   ├── Customer Web App
│   ├── Veterinarian Web App
│   ├── Veterinarian Mobile App
│   └── Backoffice Web App
└── Environments: Dev, Staging, Acceptance, Production

Project: Netflix for Pets
├── Applications:
│   ├── Web Video Player
│   ├── Admin App
│   └── Mobile Video Player
└── Environments: Dev, Staging, Production
```

**Why separate projects:** Veterinary App and Netflix for Pets have no shared user flows — they're completely separate products. Different products within the same team should typically be different Applications, not Projects. Only create separate Projects when there's no possible shared user flows (like a consultant working with isolated clients).

## Decision Guide

If you're unsure which level to use, use this decision flowchart:

```mermaid theme={null}
flowchart TD
    START(["Need to organize testing"]) --> Q1{Can user flows be shared?}

    Q1 -->|"No - completely isolated"| NEW_PROJECT["New Project"]
    Q1 -->|"Yes - same ecosystem"| Q2{Will the same tests run?}

    Q2 -->|"No - different test suite"| NEW_APP["New Application"]
    Q2 -->|"Yes - same tests"| NEW_ENV["New Environment"]

    NEW_PROJECT --> EX1["Examples:<br/>Consultant with separate clients<br/>Completely separate product lines"]

    NEW_APP --> EX2["Examples:<br/>Customer app vs Admin panel<br/>Web app vs Mobile app<br/>Frontend vs Backoffice"]

    NEW_ENV --> EX3["Examples:<br/>Dev, Staging, Production<br/>Different markets (/en, /de)<br/>Preview deployments"]
```

<Note>
  **Golden rule:** Create a new project only when there are no possible shared
  user flows. Different products within the same team should be different
  Applications, not Projects.
</Note>