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:
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.
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.
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.
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.
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.
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.