Key differences
If you're coming to Constructor from another tool, Constructor should feel deeply intuitive and familiar.
But there are some important differences and distinctive features worth highlighting:
Other tools | Constructor | |
|---|---|---|
Views into a single ticket space; tickets can appear on multiple boards simultaneously | Separate ticket spaces; a ticket can only appear on one board at a time | |
Flat comment stream, like a group chat, that's permanently visible | Assignable discussion threads that are hidden when resolved | |
Simple relationship between tickets | Flexible mechanism to capture why a ticket is stuck, regardless of the reason, and collaborate on how to get it moving | |
Linkage from PRs to tickets | Bidirectional sync that pulls in real-time details from PRs, including build status, and pushes context into them | |
Lists of tasks disconnected from your workflow | Lists of tasks connected to your workflow to make progress more visible without any extra effort | |
Fixed model with predefined levels | Flexible link-based model that lets you create exactly the structure you need for your work — and change it as necessary |
Read on to learn more.
To make it easy to understand where a ticket is and where it's going, Constructor keeps true to the metaphor of sticky notes on a whiteboard: each board is a separate space where tickets live. Tickets can be moved between boards, but a ticket can't be on more than one board at a time – and we think that's a very good thing.
Learn more:
Discussion on a Constructor ticket isn't a "group chat" stream of comments. Instead, a ticket can have multiple discussion threads, each of which is a first-class object that can be assigned to a team member and resolved when it's done. Use discussion threads to keep independent conversations separate and to model day-to-day activities like one-off requests for clarification, sign-off processes, meeting follow-up reminders, and more.
Learn more:
You may be accustomed to thinking of "blocking" as a kind of relationship between tickets. Constructor's approach is more flexible and practical.
In Constructor, a blocker is a first-class object with a short description that can be attached to a ticket, letting anyone record, assign, and discuss what's stopping progress. When a ticket has a blocker, its brief description is shown prominently on the board on the ticket's card. That makes it abundantly clear to everyone on the team not only that a ticket is blocked but also why.
Learn more:
Constructor's flexible branch-based linking mechanism makes it easy to associate code to tickets. Open PRs are displayed right on the board on the ticket's card, including their live build status, deploy preview and other CI/CD links, review requests, merge conflict status, and more, saving you clicks and making it easier to stay on top of development activity. And developers can access all of their pending code reviews right from Constructor.
Learn more:
Checklists provide a lightweight way to break down a ticket's work. And in Constructor, they have a powerful additional capability: each checklist is associated with a stage on your board. That association enables Constructor to depict the checklist's progress on the board when the ticket is in the corresponding stage, helping managers keep tabs on progress without having to pester their team for updates.
Learn more:
You're probably familiar with terms like epics, milestones, themes, or projects. Constructor supports all of these structures – and more – in a generic and lightweight model.
In Constructor, any ticket can be the parent or child of any other, and you can remove or rearrange the relationship at any time, letting you easily evolve how you organize your team's work as your needs change. And ticket hierarchies are completely optional, so you're not forced to use a heavyweight hierarchy when it doesn't add value.
Learn more:
Last modified 7mo ago