Loading
Project tools are usually sold as a board plus a set of add-ons — time tracking here, resourcing there, reporting somewhere else — each with its own copy of the project.
These are views of one plan. A task, its logged hours, the person assigned and the margin that follows are the same object seen four ways, which is why moving one moves the others.
Every entry below names the products it is joined to. Those joins are the specification, not a footnote.
Milestones and phases created from the sold scope, with dates that move together when one of them slips.
Ownership, blockers and sequence, in board or timeline, without a second tool for the plan and the work.
Who is actually available, reading real leave and attendance rather than an optimistic assumption.
Hours logged against real work items, not a free-text week, so cost and billability are the same number.
Cost against the sold value while the project runs, instead of a reconciliation after the invoice has gone out.
A shared view of status and decisions that reads the same records the team works in — no status deck to assemble.
Chat, documents, meetings and whiteboards attached to the project they belong to, so the decision and the work item are the same thread.
Sprints, velocity and burndown for teams that work in iterations, reading the same tasks the Gantt does.
Standups, client reports and delivery risk written from hours and progress already logged, not from a status meeting.
Read them as a chain rather than a toolkit. The plan holds phases and dependencies; tasks carry the work and its estimate; capacity says whether the people exist; time turns work into cost; and margin is what those three produce when they meet the contract.
The joins are what make the plan worth maintaining. A slipped dependency moves the delivery date, which moves the client view, which moves the invoice schedule — so updating a task is not reporting overhead, it is how the rest of the company finds out.
Client visibility and collaboration sit alongside rather than on top. The portal shows the same plan, filtered; the conversation attaches to the thing it is about.
Drag a card and the plan moves, the dependent work moves with it, and anything relying on that person shows the new load. There is nothing between the card and the schedule.
Not add-ons and not an enterprise tier. These behave the same whether you run one product or all seven.
If you are comparing against a project tool that works, read live margin and capacity. Those are the two most tools do not have, because both need data that lives outside a project tool.
If your problem is that nobody updates the plan, read client visibility. Making the plan the thing the client sees is what changes the incentive, and it does more than any reminder.
Yes. Every feature listed here works with Loop alone. Where one says it joins another product, that join simply waits — switching the other product on later needs no migration, because the record it wants is already there.
No. Custom fields, permissions, automations, the audit trail and the API behave the same on the smallest plan as on the largest. The list on this page is the whole list.
Work backwards from the handover that costs you most. The feature that removes a manual step between two teams is worth more than the one with the longest description.
Fourteen days, every module, no card. Or half an hour with someone who will use your own numbers.