Projects, phases and tasks

Everything in Waymarq hangs off three things.

Project

A body of work for one client. It holds the dates, the money, the team and the files.

Create one from Projects → New project. The first thing it asks is how you want to start, because not every project arrives the same way:

• I have a brief — upload it or write a few lines. The brief is what the AI planner, clarifications and spec-recheck all read, and it's stored as an ordinary file you can open later from the project's Files page.
• I'll plan it myself — straight to an empty phase list, no brief involved.
• Just a board — a Kanban board and nothing else. Budgets, time tracking and the calendar start switched off, and you can turn any of them back on in Project settings whenever you want them.
• Connect an AI agent — you get an API token and a prompt to paste into your own coding agent, which then fills in the phases and tasks for you.

Your answer is remembered, and it's the reason Waymarq stops asking a hand-planned project to upload a spec. You can change it later from the project's setup — nothing is locked in.

Waymarq suggests a name from whatever you give it — from the filename where that says something useful, and from the opening of the document itself where it doesn't. It's only a suggestion; edit it or ignore it.

Only the name is actually required. Status and dates get sensible defaults and are editable in Project settings, and the setup wizard then offers features, files, phases and tasks, and team — every step skippable.

A project has a type (development, marketing, construction, event and so on) which only tailors the suggested starter phases. It changes nothing else.

Phase

A stage of the work — Discovery, Design, Build, Snagging. Phases give the project its shape and are what the timeline and roadmap sequence.

A phase appears on the timeline once it has tasks with dates. There's nothing to configure — a phase holding nothing but backlog work simply has no bar to draw.

Marking a phase for later

A whole stage can be put aside without being deleted. On Phases & tasks, the box icon in a phase's header marks it Later: its tasks move to the backlog, so they drop out of the effort total, the delivery date, the boards and the timeline — but they're still written up, and one click brings them back.

This is for the stage a client hasn't agreed to yet, or the part of a brief that's clearly next year's problem. Deleting the phase would work too, but it throws the planning away; deferring keeps it.

Work that has already started never moves. If a phase is half underway, only the not-started tasks are parked — anything in progress, in review or done stays exactly where it is, because filing finished work as speculative would rewrite what actually happened. Waymarq tells you how many it left alone.

Task

The actual unit of work. A task belongs to exactly one phase and carries the detail: description, estimate, assignee, dates, dependencies, checklists, comments, time and files.

Assigning a task to someone makes them a watcher of it, and puts it in that night's round-up email for them — one email covering everything they were given that day, rather than one per task. They can turn the round-up off under Account → Notifications.

Status, and the backlog

A task's status is where the work has got to: Backlog → Not started → In progress → Review → Done.

Backlog is the odd one out, and deliberately so. It means work that exists but that nobody has committed to yet — an idea, a request, a "we should probably". Because it isn't committed:

• it doesn't count towards progress, in either half of the fraction, so parking an idea never drags a project's percentage down;
• it's never treated as overdue, however old a date sits on it;
• it doesn't count towards anyone's workload, so a tidy backlog doesn't read as an overloaded team;
• it isn't shown to clients on a share link, because uncommitted work shown to a client reads as a promise.

Promoting it is just moving it on — drag it out of the Backlog column on the board, or give it dates on the timeline. It keeps its phase either way: deciding to do something isn't the same as deciding what stage it belongs to.

Review is the column for work that is in somebody else's hands — a reviewer, the client, a supplier. Which brings us to:

Waiting on the client

Real plans have gaps that aren't yours: the client reviewing a proof, a printer turning the job round, content you're waiting to receive. Rather than leaving those as unexplained space, make them tasks — "Client feedback on V1", three days — and set Waiting on in the task's sidebar to the client or a named third party.

A waiting task stays in the plan: it has dates, it can be a prerequisite ("Amends" follows "Client feedback"), and it shows on the timeline. But it is not your time, so:

• it is left out of the project's effort and everyone's workload;
• it goes into Review the moment it starts, never In progress;
• it is drawn with a dashed outline and faint hatching on the Gantt and calendars;
• on the client's share page it reads "With you until…" rather than a status word that means nothing to them.

When the date passes and the task still hasn't moved, you get one email the morning after (never the client — whether to chase them is your call), and the project overview says so until the task moves on or gets a new date. Turn the email off under your notification settings if the overview banner is enough.

Your dashboard keeps it separate too. Overdue work sitting with somebody else appears under
Waiting on someone else, in amber, below your own overdue work rather than mixed into it —
waiting on a client to come back is a thing to chase, not a thing you are late on, and counting
the two together made the red number mean nothing. Each line names who has it and how long they
have had it.

Files on a task

Attach screenshots, logs, PDFs, documents or a short screen recording from the task sidebar — drag several in at once, up to 20MB each.

Every file records who sent it, including people with no account here. A screenshot a client attached to a support request keeps their name on it after the ticket became a task, rather than showing whoever accepted it — so months later it still says where the evidence actually came from.

You can also attach files from outside the app: waymarq attach W-12 screenshot.png from the command line, POST /tasks/{task}/attachments over the API, or attach_file if you have an AI assistant connected. See Integrations and the API.

Priority

Separate from status, and worth keeping separate. Status is where the work has got to; priority is how urgent it is; being overdue is neither — it's just a fact about the due date, and Waymarq works it out for you.

Four levels: Urgent, High, Normal (the default) and Low. Set it in the task sidebar, or when you create a task under More details.

On the board, only Urgent and High are coloured — a red or amber stripe down the left edge of the card. Low gets a grey stripe, meaning "you can leave this", and Normal gets nothing at all. That's on purpose: the stripe only draws the eye if most cards don't have one, so a board where everything is marked urgent tells you exactly as much as a board where nothing is. Use them sparingly and they'll keep working.

The same mark follows the task across views — a stripe on roadmap cards, a small dot beside the name on the Gantt, and a badge in the phases & tasks list.

If you plan a project with AI, it sets a priority on each task as part of the breakdown, using the same rule: most work comes back Normal, with one or two above it where the spec genuinely justifies it. It's a starting point, not a verdict — change anything that doesn't match how you see the job.

Reference codes

Every project derives a short prefix from its name, and everything gets a stable, searchable reference:

• Tasks: WR-12
• Phases: PH-WR-3
• Work orders: WO-WR-1
• Statements: ST-WR-1

These stay put if you rename the project, and they're unique across your whole organisation, so quoting "WR-12" in an email is unambiguous. You can search any of them from the search box.

Archiving a task

For work that won't be done but is worth keeping the record of, use Archive task in the task sidebar rather than deleting it. An archived task shows a banner marking it as archived, and its Archive button becomes Restore task. It drops off the boards, out of progress counts and off the client-facing share view — but nothing is lost: it stays searchable (flagged as archived) and any time logged against it stays billable. Archive cascades to a task's subtasks and restores them together. Deleting, by contrast, is permanent and lives on the phases & tasks list, deliberately away from the archive control.

How much detail to put in a task

Waymarq handles both extremes deliberately:

• A reminder — "Buy the domain name". A title is enough. Choose Quick task when creating it and the task detail view stays small: dates, status, time and not much else.
• A real piece of work — a description, a full specification, subtasks, a checklist, a verification plan. Choose Full task.

New projects default to Full; after that, whichever you picked last in a project is offered next. It's never final — every task's sidebar has a Make it a full task / Make it a quick task switch.

The rule of thumb: split into subtasks when the pieces are independently trackable — different people, different completion states. If it's one person doing one thing, keep it one task and write a longer specification instead. See Subtasks, checklists and test plans.

Doing the same job again

If the shape of a project repeats — the same stages, the same rounds — save it once and start the next one from it. See Project templates.

Structuring advice

• Phases should be stages, not categories. "Design" is a phase; "Things Priya is doing" is not.
• Aim for a handful of phases. Twenty phases with two tasks each is a list wearing a costume.
• Put dependencies only where one thing genuinely can't start before another finishes. Chaining everything in a line makes the timeline honest-looking and useless.