GitHub is a fantastic tool that's aimed primarily at a dev team's coding workflow, especially code review and build automation. Constructor, by contrast, is aimed at supporting a product development team’s overall workflow: helping PMs, designers, and managers, as well as developers, collaborate on research, design, development, testing – everything they need to do. This leads to Constructor and GitHub having different strengths and being more complementary than competitive. In Constructor, the whole product team collaborates at the level of features (or bugs/stories/epics/etc.), while in GitHub the developers collaborate primarily at the level of code changes – which usually don’t correspond 1:1 with features. For most product development teams, both systems are essential.

Different objectives usually result in different designs, and that's certainly the case here. In this post we’ll go over the major differences between Constructor and GitHub, and why we’ve made the design choices we have.

1. GitHub issues are bound to a single repository

GitHub issues are always associated with a repository, so the work is always in the context of a codebase. If a team has issues that span repositories, they either have to create a pseudo-repository that doesn’t hold any code but is just used to manage issues, or use a different tool altogether. Note that while GitHub projects can span repositories, the issues contained in projects will always be associated with exactly one repo.

Constructor, on the other hand, doesn’t tie tickets to repositories. A ticket is simply work that needs to be done and doesn’t imply or restrict which codebases are impacted (if any). On the same board, different tickets can map to work done in different codebases. In fact, even a single ticket in Constructor can be associated with pull requests to different repositories.

2. Constructor supports real discussions with threads

Conversations are the essence of collaboration. Constructor enables real, practical collaboration via discrete conversations (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 place for logging quick requests between devs and PMs, QAs and devs, etc. – all while remaining as frictionless as a chat app like Slack.

GitHub Issues, by contrast, provide an unstructured list of non-resolvable comments that are interleaved with all other activity for the issue. They get pushed offscreen (and potentially lost track of) as unrelated new messages come in, and they can't be explicitly assigned to a team member for follow-up, so balls can get dropped all too easily.

3. Constructor provides explicit 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 GitHub usually end up creating a column called “Blocked” where they put blocked issues, or using a label to indicate an issue 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.

4. Checklists and ticket progress bars

Checklists are a fundamental tool for planning and tracking work, and both GitHub and Constructor support them. In GitHub, checklists are embedded in issue descriptions using extended Markdown syntax. But in Constructor, checklists are first-class citizens that can be tied to specific stages in your workflow. This lets managers see what they really want to know, namely: "How close is this thing to moving forward in the flow?" without imposing any extra work on the team.

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 clearer picture of how the work is coming along.

In both GitHub and Constructor, checklists can contain references to other tickets, but in Constructor this creates an explicit parent-child relationship between the tickets and makes the child’s status visible on the parent card.

5. “Owner + collaborators” versus “assignee(s)”

In Constructor, every ticket can have an explicit owner – but only one – and can also have one or more collaborators. This enables teams to run a strictly-single-owner process while still keeping track of everyone who’s involved – for example, making it clear who’s responsible for the frontend work. Constructor displays owners distinctly from collaborators so it’s easy to see what’s going on.

In GitHub, depending on your plan, issues can have either a single assignee or up to ten assignees in a flat, undifferentiated list. But many teams want a hybrid where there’s both a clear owner and a complete list of everyone involved – which is distinct from the list of people watching the ticket. This is the model provided by Constructor.

6. Constructor has actual backlog support

Every Constructor board has 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.

7. Constructor boards have simple, real-world semantics

Constructor has a simple model inspired by the real world where a ticket always belongs to exactly one board, rather than boards being arbitrary views into a shared pool of tickets. Tickets can be moved between boards, but the idea is that a board is a long-lived shared space with a clearly defined workflow, tied to a specific team – very much like the stickies on a wall that many teams still use. This makes it easy for everyone to understand what's going on without getting confused.

By contrast, GitHub Projects are a layer on top of GitHub Issues: projects contain references to issues (and pull requests), not the issues themselves. So by default, issues exist without being included in any project, making it easier for them to get lost in the shuffle. Also, projects track issues and PRs independently, so it’s possible that a PR and the issue it's for appear on the same project in different positions or in different projects entirely.

8. Constructor is great for the non-devs, too

Many PMs we’ve spoken with find GitHub overwhelming because it’s designed primarily for developers. By contrast, we’ve designed Constructor from the ground up to delight everyone on the team – developers, designers, PMs, testers, everybody – without compromising the experience for any individual role. If your team is only developers this difference won’t impact you much, but if you have any PMs or designers, our research suggests they’ll probably prefer the more focused and streamlined experience of Constructor.

In Conclusion

While it’s understandable that a team would want to track their work alongside their code and not add another tool to the mix, GitHub Issues imposes a severe constraint in how work items can be organized and has only basic support for collaboration. Not only does Constructor directly address those weaknesses, by tightly integrating with GitHub it lets teams employ each tool where it’s strongest.