For AI agents: a documentation index is available at /llms.txt. A markdown version of this page is available at /guide/cloud/projects/create-a-project.md.

CloudProjects

Create a project

Set up a project properly the first time — naming, dates, members and the settings that matter later.

A project is the container for tasks, milestones, files, time and reporting. Everything else hangs off it, so the few minutes spent here pay back.

#Create it

  1. Projects → Create

    Or start from a template if you have one that fits.

  2. Name and short name

    The short name prefixes every task reference — WR-142 — so keep it to two or three characters and make it unique. It appears in every standup, commit message and conversation, and changing it later invalidates references people have already written down.

  3. Type and status

    Project type drives some reporting groupings. Status is Started, Hold, Stack or Completed.

  4. Dates

    Start and end dates are optional but feed the Gantt chart, calendar and portfolio views. A rough estimate beats leaving them blank.

  5. Members

    Only members see the project. Add them now — an invited user with no project membership sees an empty workspace.

#Naming that scales

At five projects any naming works. At fifty it decides whether people can find anything.

Do

Name after the deliverable or client: "Acme — Website Redesign". Prefix consistently if you have client work.

Don't

Name after time periods ("Q3 Work") or people ("Priya's Projects"). Both stop making sense within months.

#One project or several?

One project per sprint?

No. Sprints live inside a project. A project per sprint scatters your history and breaks velocity tracking.

One project per client?

Good if each client is one ongoing stream of work. If a client has several distinct deliverables with different teams, split them and group with programs on Premium.

One project per team?

Works when a team owns a continuous product. Use milestones for the delivery points.

One giant project for everything?

Only at the very start. Filters stop being enough surprisingly quickly, and per-project reporting becomes meaningless.

Basic has a 10-project cap

If you create a project per client or release on Basic, count them before you design the structure. Pro and Premium are unlimited.

#Set up before you invite people

Two settings are much easier to get right before there is data:

📊Statuses

On Pro and above, define your custom statuses first. Renaming later leaves tasks in columns whose meaning has shifted.

🏷Custom fields

Add the two or three that genuinely drive decisions. Adding fields later is fine; back-filling them across 400 tasks is not.

#Members and visibility

Project membership controls visibility. Admins see everything regardless.

On Pro and above, manage membership through teams rather than individually — far less churn when someone joins or moves.

Removing a member does not reassign their tasks

Their tasks stay assigned and disappear from the team's normal views. Reassign first.

#Archiving

Set status to Completed and filter it out. Keep the data — it feeds historical reporting and estimates.

Deleting is permanent

Deleting a project removes its tasks, comments, attachments and logged time with no undo. Archive unless you are certain.

⚙️Next: project settings

Everything you can configure once the project exists.