When people meet Constructor for the first time, they’re often reminded of Trello. That’s not surprising, because Constructor was heavily inspired by Trello’s simplicity, and many of our users view Constructor as a natural evolution of Trello. But despite the resemblance, Constructor differs from Trello in ways large and small, and it’s helpful for teams coming from Trello to understand the major differences. So here they are.

1. Conversations

In Constructor, comments are always part of discrete conversations (called threads) that can be assigned and resolved. Open threads are unmissable in a dedicated area on the right hand side of ticket pages, but when resolved, they’re hidden to minimize clutter. They’re the perfect tool for quick requests between devs and PMs, QAs and devs, etc., all while remaining as frictionless as a chat app like Slack.

In contrast, Trello displays comments in a single unstructured stream that's inverleaved with other card actions and events. They get pushed offscreen (and potentially lost track of) as unrelated new messages come in, and they can't be assigned to a team member for follow-up, so balls get dropped all too easily.

2. “Owner + collaborators” versus “members”

In Trello, cards can have any number of “members” in a flat, undifferentiated list. But many dev teams prefer each job to have a single unambiguous owner.

Constructor provides a flexible ownership model that supports both ways of working. Every ticket may have an owner – but only one – and can also optionally have one or more collaborators. Teams can run a “strict single owner” process if they like, or they can tag a ticket with everyone involved while still designating a single person as ultimately responsible. Constructor displays owners slightly differently from collaborators so it’s easy to understand what’s going on.

3. Proper support for the backlog

One of the biggest headaches when using Trello for managing software development is representing a backlog as an always-visible list of cards; it works well for up to around a dozen items before becoming unwieldy and distracting.

Constructor’s UI design is different. Every Constructor board features a dedicated backlog that’s optimized for managing lists of ~100 tickets, and it’s hidden away by default. The backlog can be “pulled out” with a single click or keypress and stashed away just as easily. The idea is that the board should always be focused on the work being done right now, or coming up imminently, without a long backlog distracting the team.

4. Workflow modeling

Trello bills itself as a tool for managing “lists of lists”. Constructor is a bit more specialized – it’s designed for managing a workflow, which is modeled as a partially-ordered set of queues called stages. A stage is still displayed in the familiar form – as a column on a board – but Constructor’s approach enables additional capabilities.

Each stage in Constructor is categorized as either waiting, working, or complete. A stage’s category is referenced throughout the system. For instance, checklists can be tied to working stages so that the checklist status is visible on the card when the card is in that stage. Also, cards with child tickets display progress bars showing where each child is in its respective workflow, and these progress bars are color-coded according to whether the ticket is currently in a waiting stage (gray), in a working stage (green), is blocked (red, see below), or is complete (blue). When a new board is created, it’s given one stage of each type to start with.

5. Checklists and per-stage progress

Checklists are a wonderfully useful tool that both Trello and Constructor provide strong support for: in both products you can have as many checklists as you like and call them what you like.

Where Trello and Constructor primarily differ is in how a checklist’s progress is reported. In Trello, a card’s progress is indicated simply as the fraction of all its checklist items that are completed, regardless of which list the card is in. But as explained above, Constructor is a tool for modeling workflows, and as part of this model, checklists can be tied to particular stages, letting Constructor indicate a ticket’s progress per-stage. That lets managers see what they really want to know, namely: how close is this thing to advancing to the next stage?

For instance, let’s say your ticket has one checklist called “Design Tasks” tied to your Design stage, and another checklist called “Test Plan” tied to your QA stage. Both of these lists can be collecting tasks while the card is in the Design stage, but the progress indicated on the card will only reflect progress for the current stage’s checklist, giving you a better idea of how the work is coming along.

6. GitHub integration

Trello’s GitHub integration is a “Power-Up” – a plugin that can be bolted on. It requires teams to manually link each pull request to a card. By contrast, Constructor’s GitHub integration is native and works extremely closely with GitHub, as you’d expect for a tool built for software teams.

In Constructor, PRs are automatically detected and attached to tickets based on branch name. (Constructor suggests a branch name to make things easy, but any branch name starting with the ticket ID will do.) The GitHub integration is also bidirectional: when Constructor notices a new pull request in GitHub, it not only pulls its details into Constructor, it pushes the context from the Constructor ticket (the description, including any links, images, etc.) into GitHub as a comment on the PR. Whoever is doing the code review doesn’t even need to open Constructor to get the context they need to understand what the code is trying to do. Finally, whereas Trello only shows whether a PR is open or merged, Constructor puts all the details of the PR – build status, diff stats, and who’s tagged for review – right on the card. And if your team uses Netlify, you get a link to the Netlify deploy preview as well. If a PR has been open for too long (24 hours by default, which is how most teams seem to operate), Constructor highlights it on the board as a gentle nudge to get it moving.

7. Hierarchy

Most teams eventually hit a point where they need to track work at multiple levels. For example, a product manager may want to operate at the level of features, and perhaps a higher level of milestones, whereas the dev team wants to operate at the level of stories or smaller tasks. Both Trello and Constructor support including references to other cards as checklist items, but Constructor takes this further with explicit parent/child relationships.

In Constructor, any ticket can have child tickets, and those children can be on any board, including the same board as the parent. For example, a product manager could quickly create a new board called “Features” and then create an item on that board for every feature in flight and coming up, attaching all the open dev tickets to their respective features. This way the PM can keep tabs on the progress of all the features without impacting how the dev team operates at all. And the dev team can happily work on tasks – such as devops chores – that don’t pertain to any particular feature without getting tangled up in an inflexible model that demands a consistent structure.

In fact, Constructor allows tickets to be arranged in a directed acyclic graph. For example, tickets can have multiple parents, allowing teams to model, say, a refactor that supports two separate features and is a dependency for both. The only constraint is that cycles aren’t permitted.

And while in Trello a task can be converted to a card, the new card is no longer connected to the card from which it originated. By contrast, Constructor supports “promoting” a task to a ticket such that the original task is replaced by a reference to the newly-created ticket. This lets teams quickly create draft breakdowns as lightweight tasks, then promote tasks to heavier-weight child tickets only as necessary.

8. Blockers

One of the things great managers do is obsessively find and remove obstacles blocking their teams’ progress. To keep track of tickets that are blocked, teams using Trello usually end up creating a list called “Blocked” where they put blocked cards, or using a label to indicate a card is blocked. But we feel that managing blockers is so important – and those solutions so inadequate – that they deserve explicit support.

In Constructor, you can create blockers on a ticket to capture a brief description of what’s blocking progress. Blockers build on discussion threads, so they also provide a place where the issue can be discussed and resolved. And blockers are displayed very prominently on the cards on the board so everyone can see there’s a problem as soon as it’s reported. You can learn more about blockers in our blog post introducing them.

9. The “My work” menu

Both Trello and Constructor support multiple boards as a solution to partitioning a team’s work, whether by level in the hierarchy, system, or sub-team. But this makes it harder for individuals to see all their work in one place. To solve this, Constructor provides a menu in the nav bar called “My work” that shows everything on your plate. It includes not just tickets you’re an owner or collaborator on, but also PRs you’ve been tagged to review and discussion threads you’ve been assigned to follow up on.

You can see all these features in action in our instant demo, and if you'd like to experiment with Constructor using your actual data, you can import your Trello board into Constructor in about 30 seconds under Settings | Import data.