Subtask Management Software
Straight answer first: ShipSprint doesn't have a separate subtask hierarchy nested under a parent task. Here's what handles the same need, and why it's built that way.
The honest version, before the pitch
A lot of tools let you nest a task three or four levels deep, task, subtask, sub-subtask, until the board looks like a file tree. ShipSprint doesn't do that. There's one kind of card, and it doesn't have children.
That's a real limitation if what you're picturing is a checkbox list nested inside a parent card. It's not a limitation if what you actually need is to break a big piece of work into pieces small enough to finish. ShipSprint just does that at the board level instead of inside a single card.
The rest of this page is about how that plays out in practice, because "we don't have subtasks" is a strange thing to lead a feature page with unless we also tell you what to do instead.
It's also worth saying plainly why this page exists at all: people search for "subtask management" because a competitor's marketing has trained them to expect a specific nested UI, and the honest answer to "does ShipSprint have that" is more useful than a vague page that dodges the question.
What replaces a subtask tree
Three habits, not one feature, cover most of what a subtask hierarchy is used for.
Instead of nesting five subtasks under one card, split the work into five cards. They queue through triage and the same column WIP limits like anything else, the breakdown lives in the board's structure, not inside one card's checklist.
Draft the plan as prose in ShipSprint's built-in wiki, first the API, then the migration, then the interface, and any sentence on the page can become a task on its own. The breakdown starts as a plan, not a form filled in field by field.
On Team plan and up, a feature naturally splits along its GitHub branches, each branch moves its own card, each merged pull request closes its own card, so a large feature decomposes without anyone manually building a tree.
Because a column has a cap, cramming an oversized task into one card runs into the same limit as anything else, the ceiling nudges you toward cutting work down rather than nesting it deeper.
A breakdown, worked through
Say the ask is "redesign checkout." In a tool with nesting, that becomes one parent card with six subtasks tucked inside it, API changes, new UI, payment provider testing, analytics events, copy review, rollout plan, all invisible unless someone expands the parent.
In ShipSprint, the same breakdown starts as a wiki page: a paragraph laying out the approach, one sentence per piece of work. Each of those sentences becomes its own card, six cards, not one card with six hidden rows. They queue through triage individually, so the API change can start this sprint while the copy review waits for a slot next sprint, instead of all six being trapped behind one parent's status.
If three of those cards happen to be engineering work with their own branches, each branch moves its own card and each merge closes its own card, the breakdown keeps decomposing itself as the code gets written, without anyone maintaining a checklist by hand.
The result looks like six cards scattered across a board instead of one tidy parent. It also means none of the six can quietly stall unnoticed behind a collapsed arrow, each one is subject to the same WIP limit and the same forecast as everything else on the board.
Why not just add nesting?
Nested subtasks solve a display problem, collapsing detail so a board looks tidy, but they create a tracking problem: work buried two levels deep doesn't show up in a WIP limit, doesn't get its own forecast, and is easy to lose behind a collapsed arrow. A board that looks calm because detail is hidden isn't actually calm.
Sibling cards cost you a tidier-looking board. In exchange, every piece of work, however small, is visible to the same WIP limit, the same forecast and the same "I'm blocked" flag as everything else. For most teams that trade is worth making, which is why ShipSprint is built this way rather than the other way. It's also why a stalled piece of "redesign checkout" gets caught in a day instead of a week: there's no collapsed row for it to hide in.
There's a second, quieter reason: nesting tends to encourage over-planning. It's easy to sit down and sketch eleven subtasks under a parent before any of them are actually understood, because the nested list makes planning feel like progress. Writing a wiki paragraph and turning sentences into cards as the plan solidifies keeps the breakdown closer to what's actually known at the time, rather than a speculative tree drawn on day one and rarely revisited.
When this genuinely isn't the right fit
If your process specifically requires a formal work breakdown structure, a parent deliverable with tracked child items rolled up for compliance or contractual reporting, the kind some construction or heavy-regulation projects need, ShipSprint's flat-card approach won't reproduce that on its own. Sibling cards linked by a label are a workable stand-in for most teams, but they're not the same as an enforced hierarchy with rollup reporting built into the object model.
For the more common case, an engineering feature, a marketing campaign, an HR process that just needs breaking into doable pieces, the wiki-to-task flow and per-branch cards cover it well. It's worth being clear about which situation you're actually in before assuming either way.
What it costs
- Free covers boards, triage and the wiki-to-task flow for up to 5 users and 2 projects, no time limit.
- Team (₹299/user/month, ₹2,899/year) adds GitHub branch-to-card sync, the closest thing to automatic breakdown for engineering work.
- Business (₹599/user/month, ₹6,499/year) adds forecasting so a swarm of small cards still rolls up into one delivery date; every paid plan gets a 14-day full-access Business trial, see pricing.
Common questions
Correct, no parent-child task nesting. What exists instead is small sibling cards, a wiki page you can turn line-by-line into tasks, and, for engineering, one card per branch. For most breakdown needs that covers it; if you specifically need a collapsed checklist inside one card, ShipSprint doesn't offer that today.
It makes the board more honest rather than tidier. You can group related cards by label or column instead of nesting, so the breakdown stays visible rather than collapsed out of sight.
The same way any card does, they count against the column's cap. That's actually useful: it stops a "quick breakdown" from quietly turning into fifteen cards nobody can finish at once.
We're not ruling it out, but the current design is a deliberate bet that flat, small, visible cards track better than nested ones. If that changes, it will be a real feature, not this page rewritten.
Labels and the wiki page they came from. The wiki page that generated the breakdown stays linked to the cards it produced, so you can always get back to "everything related to checkout" without a parent-child structure enforcing it.
Yes, the wiki-to-task flow isn't engineering-specific. An HR onboarding overhaul or a marketing launch plan breaks down the same way: write the plan as prose, turn each piece into its own card, let triage and WIP limits handle the rest.
No, the structure is still there, it's just horizontal instead of vertical. A WIP limit, a triage step and a linked wiki page are real constraints; they just don't take the shape of a nested tree, which is a specific UI choice rather than a proxy for how much rigor the system enforces.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required