Projects: Current Operating Model

Status: current implementation and decision guide Last reviewed: 2026-08-01

What this document is based on

Statements labeled Current describe behavior found in the app and backend as of the review date. Product problems come from direct owner feedback while using the app.

There is not yet customer research, product analytics, or a usability study that validates a new Projects layout. The options in this document are decision prompts, not evidence that one answer is better. In particular, the removed task dashboard and Priority/Up next layout came from generic project-management patterns, not evidence from this product or its users.

The simple version

A project is a client-owned delivery container.

It answers:

1. What are we delivering?
2. Who owns the work?
3. What needs to happen next?
4. What are we waiting on from the client?
5. What has the client been told?

A project is not required for every client interaction. Invoices, subscriptions, contracts, files, notes, and time can exist without a project when that reflects the real work.

How the parts fit together

Client
└── Project
    ├── Tasks and subtasks       organization-owned work
    │   └── Requests             something needed from the client to continue
    ├── Updates                  authored news and meaningful task events
    ├── Project files            files owned by this delivery context
    └── Linked context           time, notes, contracts, quotes, invoices, subscriptions

The project owns tasks, updates, and project-specific files. Other records keep their own source of truth and link to the project only when the relationship is real.

Where Projects appears

Client overview

The client overview is the simplest entry point. It shows the client's current projects, project status, the latest update, and a direct action to add an update.

Projects workspace

The top-level Projects workspace is the cross-client operating view. It provides board and list views, search and filters, and the ability to inspect work across all accessible clients.

Project workspace

The primary project navigation is:

• Overview — project identity, status, owner, target date, latest client update, and current tasks.
• Tasks — the work queue, subtasks, client dependencies, context, comments, linked updates, time, and completion.
• Updates — authored project news and automatic task events.
• Files — project-owned files, documents, requests, and resources.
• Time — tracked work, approval, budget/cap usage, and invoice readiness.
• Notes — internal working memory linked to the project.
• Billing — contracts, quotes, invoices, and subscriptions explicitly linked to the project.

Today

Today is the cross-project task view. It does not create a second task system.

Client portal

The portal is a reduced client-facing projection. It is not a second project manager.

Project record

A project currently stores:

• client;
• name and summary;
• status;
• lead and project team;
• target date;
• time billing mode: hourly, retainer, or non-billable;
• optional hourly rate, estimated hours, and capped hours;
• whether approved tracked-time totals appear in the portal; and
• linked operational and commercial records.

Projects are currently client-visible by default. Internal work should use internal notes, time entries, task context, or internal files instead of an internal project.

Project lifecycle

Status	Current meaning	How it changes
Planned	Accepted or defined, but not in active delivery	Selected manually
Active	Delivery is underway	Selected manually
Blocked	Delivery cannot continue	Created by recording a blocker with cause, owner, and next action
Complete	Delivery is considered finished	Selected manually
Archived	Removed from active operation but retained	Explicit archive action

Current rules:

• A project cannot be marked blocked without recording why.
• Open blockers must be resolved before another normal status can be selected.
• Completing a project is currently manual; open tasks do not automatically prevent it.
• Archiving retains project history and archives project-owned files.
• Permanent deletion is restricted and blocked while linked records remain.

Tasks

Tasks are the execution layer. They answer: what must happen next?

A parent task currently has:

• title and description;
• priority: low, normal, high, or urgent;
• due date;
• assignee;
• open or completed status;
• internal notes and links;
• tracked time;
• linked updates; and
• lightweight subtasks.

The Tasks tab uses the available workspace width as an operational list rather than stretching each task into a wide card. On large workspaces, assignee, due date, priority, tracked time, and direct actions align into stable columns. On smaller workspaces, those fields collapse beneath the title so the list remains usable without horizontal scrolling. Completed work uses the same layout.

Subtasks

Tasks support one level of subtasks.

• A subtask is an inline checklist row inside its parent, with only a title and completion state in the interface.
• Subtasks are added during parent-task creation or directly from the parent row and task sheet.
• Subtask titles are renamed inline; subtasks do not open a separate editor, working tab, timer, request workflow, or project-level update.
• A subtask cannot have its own subtask.
• A parent cannot complete while a subtask is open.
• A parent cannot be deleted while subtasks remain.
• Reopening a subtask reopens its completed parent.

Task workflow state

The app also derives a working state from client collaboration:

State	Meaning
Ready	Work can begin
In progress	Work is underway
Waiting on client	A blocking request is outstanding
Ready for review	The client submitted something that needs review
Paused	Work is intentionally paused

This is separate from open/completed. It describes what is happening now, not whether the task is finished.

Task completion rules

A task cannot complete while it has:

• an open subtask; or
• an unresolved request.

A task also cannot be deleted when retained history depends on it, including linked time or updates.

Current visibility rule

All newly created project tasks are currently client-visible. The client portal does not expose assignee identity, internal task context, internal notes, or raw time entries.

This default is one of the most important product decisions still requiring confirmation.

Requests

A request is attached to a task. It answers: what exactly do we need from the client to finish this task? It is not a second task.

Supported types are:

• file;
• content;
• answer;
• approval; and
• other action.

A request can include instructions, a due date, and whether it blocks the task. The client can submit a response in the portal. The team can accept it, request changes, cancel it, or continue the conversation.

Requests drive the task's Waiting on client and Ready for review states. A normal comment does not.

Updates

Updates are the project timeline. They answer: what changed?

They remain separate from tasks because:

• task edits are routine internal operations;
• an automatic completion entry records a project fact without turning the task into an authored message;
• one update may summarize several tasks; and
• publishing is an intentional client-facing event.

An update can be:

• authored directly, whether or not it relates to a task; or
• created automatically when a parent task is completed or reopened.

Current behavior for authored updates:

• drafts are private to the organization;
• an update may link several tasks from the same project;
• a draft can be started directly from a task with that task preselected;
• published updates appear in the client portal and client activity/review surfaces;
• publishing does not currently send an email or in-app notification by itself;
• a published update can return to draft or be archived; and
• anything that has been published is retained and cannot be permanently deleted.

Automatic entries are limited to meaningful parent-task status changes. Subtask completion and routine edits stay inside the task and do not generate timeline noise.

Files, time, notes, and billing

Area	Current project behavior
Files	Project-specific files live in the project and use shared storage infrastructure. File requests may fulfill a task request.
Time	Time entries may link to a project and optionally a task. The project controls billing treatment, rate override, estimate/cap, and portal time-total visibility.
Notes	Project notes are internal and remain owned by Notes.
Billing	Contracts, quotes, invoices, and subscriptions appear only when explicitly linked to the project. Projects are not required for billing.

What the client currently sees

The portal may show:

• project name, summary, status, and target date;
• open project tasks, their subtask checklist, priorities, and due dates;
• requests and their conversations;
• updates;
• shared project files and resources;
• approved billable-time totals when enabled; and
• recent client-visible project activity.

The portal does not show:

• update drafts;
• project notes;
• task assignees;
• internal task context;
• raw time entries or team time notes;
• project estimates or caps; or
• internal files.

Typical operating flow

1. Create a project under a client.
2. Set the lead, status, target date, and billing treatment.
3. Add the work as tasks and one-level subtasks.
4. Attach a request when progress depends on the client.
5. Work from the project or the cross-project Today view.
6. Add an update when something needs to be said beyond automatic task events.
7. Link time, files, notes, or commercial records only when they genuinely belong to the project.
8. Complete the project when delivery is accepted or operationally finished.
9. Archive it when it no longer belongs in active work.

Current product assumptions

These explain the current model. They are not validated product outcomes and should change when actual client work shows they are wrong:

1. The client is the parent of a project.
2. Projects are optional. Do not require them for billing, files, notes, or time.
3. Tasks and updates are separate but connected. Tasks run the work; Updates record what changed.
4. Requests belong to tasks. A comment should not silently become a request or blocker.
5. Subtasks stop at one level. Do not add arbitrary task trees yet.
6. Other features keep their own source of truth. Projects link to them instead of copying them.
7. The portal stays simpler than the agency workspace.

Decisions that still need an answer

Decide these before adding more project features.

1. Should every task be visible to the client?

Current: Yes. Every new task is client-visible. Internal context remains hidden.

Options:

• Keep every project task visible.
• Add an internal/client-visible choice per task.
• Keep internal tasks private and expose only requests plus selected deliverables.

What would settle it: Test real projects containing both internal work and client commitments. Record which tasks would be unsafe, confusing, or noisy in the portal before changing the visibility model.

2. What should publishing an authored update do?

Current: It appears in the portal but does not automatically notify the client.

Options:

• Portal only.
• Always notify portal members.
• Let the publisher choose recipients and channels each time.

What would settle it: Decide whether “Publish” means “make available” or “send to the client,” then test that expectation with the first authored update.

3. What makes a project complete?

Current: A user selects Complete manually, even when tasks remain open.

Options:

• Keep completion fully manual.
• Block completion while open tasks or requests remain.
• Allow completion with a clear warning and explicit override.

What would settle it: Observe whether real projects are intentionally closed with administrative tasks still open. That determines whether completion should be unrestricted, warn, or block.

4. What should a project overview optimize for?

Current: Status, ownership, target date, latest published update, and a small open-task list.

Decision: Choose one primary promise:

• run today's delivery work;
• prepare the next client communication; or
• report project health.

What would settle it: Name the one question the overview must answer during normal client work, then remove anything that does not help answer it.

5. Do projects need milestones or deliverables?

Current: No. Projects use tasks, target date, files, and updates.

There is currently no evidence that another record type would help. Capture the first repeated case that tasks, files, and updates cannot express before deciding whether the missing concept is a milestone, deliverable, or something else.

6. Do projects need templates?

Current: No.

There is currently no evidence for a template model. Record repeated setup work first, including exactly which project settings, tasks, and requests are copied.

Explicit non-goals for now

• sprints;
• kanban configuration beyond the existing portfolio board;
• arbitrary-depth task trees;
• dependencies and critical paths;
• custom statuses or workflow builders;
• resource-capacity planning;
• per-task estimates;
• automatic updates for routine edits and minor activity; and
• making projects mandatory for the rest of the app.

Next decision session

The next Projects pass should begin by answering, in order:

1. Task visibility.
2. Client notification on update publication.
3. Project completion rules.
4. The single job of the Overview page.

Do not add milestones, templates, dependencies, or new project record types until those four decisions are settled and tested against real client work.