Projects
A bundle of tasks, bigger than a task. The workhorse of project management in Based.
When to use a project
A project is the right shape any time work is larger than a single task but doesn't need a hard ship date or a fixed time window. “Customer onboarding flow,” “Q2 marketing site,” or “Backend rewrite” are all projects.
A bare project has no required dates and no exit criteria — just a name, a status, and the tasks that roll up into it. Most teams stop here forever and never need anything heavier.
Fields
- Name — what the project is called
- Status — active / paused / archived
- Description — free-text context
- Assignees — who owns it (optional)
- parentId — optional. Blank = top-level project. Set it to another project's id and this becomes a subproject. See Subtasks & Subprojects.
Tasks roll up into projects
Every Task has an optional projectId. Set it and the task counts toward the project's rollups: total tasks, completion %, earliest start, latest end. You don't have to group tasks under a project — but when you do, the project page shows the rollup automatically.
Project flavors
A project can opt into a workType to take on extra fields and views. The bare project is the default — pick a flavor only when you need what it adds:
- Milestone — adds a definition of done, no target date. Use for the next big step on a roadmap when you don't know when it ships.
- Initiative — adds a target date and a definition of done. Use when work has a single ship moment.
- Cycle — adds a start and end date window. Use for sprints or other fixed time brackets.
- Workstream — marks the project as perpetual. Use for ongoing work that never “ships.”
Flavors are additive — under the hood every flavored thing is still a Project. Same views, same rollups, same hierarchy field. Only the extra fields differ.