Problem

Right now, all Vercel Projects live in a single flat list under a Team. As the number of deployed apps grows (frontend, backend/API, admin dashboard, docs site, marketing site, internal tools, etc.), the dashboard becomes hard to navigate. There's no way to express that several Projects actually belong to the same product or initiative.

For example, a single product might consist of:

• myapp-web
• myapp-api
• myapp-admin
• myapp-docs

Today these show up as four unrelated entries in the project list, with no visual or structural link between them, even though conceptually they're all "myapp."

Proposed solution

Introduce a logical grouping layer above Projects — essentially a "Project Group" or "Application" concept — so teams can organize their Vercel Projects the way they actually think about their systems:

1
Team
2
 └─ Group / Application (e.g., "MyApp")
3
      ├─ Project: myapp-web
4
      ├─ Project: myapp-api
5
      ├─ Project: myapp-admin
6
      └─ Project: myapp-docs

Key capabilities this could enable:

• Create/manage groups in the dashboard, and assign existing Projects to a group (many-to-one, or possibly Projects tagged with multiple groups).
• Collapsible group view in the Projects list/sidebar, so related Projects are visually nested instead of flat.
• Group-level overview showing aggregated status: deployments, domains, env var drift, build health, etc. across all Projects in the group.
• Filtering/search by group or tag in the dashboard and via the CLI/API.
• Optional shared settings at the group level (e.g., shared env vars or team access) that Projects can inherit, reducing repetitive configuration across related Projects.

Alternative / lighter-weight version

If a full hierarchical structure is too large a change, even simple tags/labels on Projects (with the ability to filter/group the dashboard by tag) would solve most of the pain point. This is similar to how AWS, GCP, and other cloud consoles let you tag resources and pivot the view around tags.

Why this matters

• Teams running microservices or multi-app products currently have no way to represent relationships between Projects.
• It becomes hard to onboard new teammates or audit "everything related to X" without external documentation.
• As teams scale past a handful of Projects, the flat list becomes a real usability bottleneck.

Possible references

Similar patterns exist elsewhere for inspiration: GitHub's "topics"/labels, AWS resource tags with tag-based console filtering, and folder/workspace groupings in tools like Linear or Notion.