Does Basecamp 5 have real subtasks?

What can a Basecamp 5 subtask actually hold?

An assignee, a due date, and its own completion state. Those three things are what separate a real subtask from a checklist item, and Basecamp's documentation is direct about all of them: subtasks can be assigned to a person and given a due date, and each subtask can be completed independently without affecting the overall to-do.

That independent completion is the part that does the most work day to day. It means a to-do can be genuinely in progress, with two of its five pieces done and owned by different people, without anyone having to update a status field or leave a comment explaining where things stand. The parent stays open until the work is actually finished.

Adding them is part of creating a to-do rather than a separate step. You give the to-do a title, then add notes, assign it, add subtasks, and set a due date, all in the same place.

It is worth looking at what that panel does not contain. There is an assignee field, a due date, and a completion circle, and that is the full set. The notes field and the comment thread belong to the parent to-do above it, which is the practical shape of the limitation described in the next section.

What Basecamp subtasks do, and where they stop

Most of what gets written about Basecamp task structure is describing an older version. Here is the current picture, based on what Basecamp documents for Basecamp 5.

On comments, be careful how you read that row. Basecamp documents commenting at the to-do level, where you can subscribe to a to-do and get notified when someone comments on it or completes it. It does not describe subtasks carrying separate threads. In day to day use that is usually a feature rather than a gap, because a single conversation about a piece of work is easier to follow than five fragmented ones. It only bites when two subtasks are owned by different people who need to talk about different things.

What most comparisons miss: the structure above the to-do

Arguments about subtask depth usually ignore that Basecamp gives you two organising layers above the to-do, and using them well removes most of the pressure to nest deeper.

To-do lists are the first layer, each with a progress pie chart showing how much is done. Groups are the second: select several to-dos, group them, and you have a labelled block inside a list. Basecamp suggests grouping by phase, team, or category, which is exactly what people usually want a second level of subtasks for. Groups can be reordered and dragged between, and if one outgrows its list you can turn it into a list of its own.

So the real hierarchy is project, then list, then group, then to-do, then subtask. That is five levels of structure, not two. Teams who say Basecamp cannot handle their breakdown have often only found two of them, which is a discoverability problem rather than a capability one.

Two smaller things are worth knowing while you are in here. Loose to-dos let you capture something without deciding where it goes, and you can file it into a list later, but clients cannot see loose to-dos, so anything a client needs visibility of has to live in a proper list. And recurring to-dos handle repeating work on a daily, weekly, monthly or custom schedule, with one primary to-do controlling the series.

When does one level of nesting stop being enough?

When your work has phases that each contain multi step tasks, and the steps themselves need owners. That is the shape Basecamp's structure resists, and no amount of grouping quite fixes it.

Take a website build for a client. The phases are discovery, design, build, and launch. Inside design there is a homepage mockup, which itself involves a wireframe, a first draft, an internal review, and a client review, each with a different owner and date. In Basecamp you can model four of those five levels comfortably. Design becomes a group or a list, the homepage mockup becomes a to-do, and the four steps become subtasks with their own owners and dates. That works.

It stops working when the client review generates three rounds of revisions that each need their own owner and deadline. Those are subtasks of a subtask, and there is nowhere for them to go. What teams do instead is promote the homepage mockup to its own to-do list, at which point the design phase stops being one visible block and becomes several lists that need mentally reassembling. Do that across four phases on three concurrent client projects and the project stops fitting on one screen.

The other thing that shows up around the same time is the absence of dependencies. Basecamp will happily let the build to-do sit unstarted while the design it depends on drifts, and nothing surfaces that except somebody noticing. For teams running sequential work with real handoffs, that is the gap that costs more than nesting depth does.

Who is Basecamp 5 a good fit for now?

Better than its reputation suggests, and the subtask addition closes the most common complaint about it. But the fit is still specific.

A good fit for checklist shaped work

If your projects are mostly tasks with steps, owned by one team, moving start to finish, Basecamp 5 handles that cleanly and with far less setup than the alternatives. Teams this far toward the simple end sometimes find a plain task list is enough, and Basecamp sits only slightly above that. The deliberate flatness is doing you a favour. Nobody spends an afternoon configuring hierarchy, and there is exactly one obvious place to put things.

Workable with effort for client project work

Agencies can run client projects here, and plenty do, but they should plan the structure up front rather than discovering it. Decide early whether a phase is a list or a group, keep the deepest breakdown at subtask level, and remember that loose to-dos are invisible to clients. The friction is manageable if the shape is chosen deliberately and everyone follows it.

A bad fit when work depends on other work

If you need one task to block another, roll progress up from subtasks to a parent percentage, or report across several projects at once, Basecamp is not the wrong tool by accident. It is a considered position about what a project tool should not do. Fighting that position is a losing game. If it is specifically the task breakdown you have outgrown rather than Basecamp as a whole, the better options for task tracking are a narrower place to start than a full replacement. Teams who need dependencies and roll-ups should look at Basecamp alternatives rather than trying to bend it.

The short answer

Basecamp 5 subtasks are real. They carry an owner, a date, and their own completion, which covers the large majority of task breakdown that teams actually need. The limit is depth: one level down, discussion at the parent, no dependencies. If your work has phases inside phases with owners at every level, you will hit that limit, and you will hit it while the project is live rather than while you are evaluating.

The practical test takes five minutes. Take your most complicated current project, write out its real structure, and count the levels where somebody needs to own something and be held to a date. Four or fewer, and Basecamp's lists, groups, to-dos and subtasks will hold it. Five or more, and you are going to be splitting lists to compensate.

If you land on the wrong side of that test but do not want an enterprise tool as the cure, it is worth seeing how a middle option handles it. In Breeze, a task can hold to-do lists and individual to-dos inside it, so one card carries several grouped strands of work rather than one flat set of steps. Each to-do takes its own assignee, due date, and time estimate, which is the part that changes what you can answer: because the estimates sit on the pieces rather than only on the card, you can see what a half finished task still has left in it. Task dependencies then cover the sequencing that Basecamp deliberately leaves out.

That is a different tradeoff rather than a strictly better one. Basecamp's flatness is a real feature, and if it currently fits your work, switching tools to gain one level of nesting would be a poor trade. That calculation is worth doing honestly, because migrating costs more than people expect.

Basecamp ships changes regularly, and everything above reflects the documented behaviour of Basecamp 5 at the time of writing, so check their current help pages before making a decision.