Show HN: Constructor – simple issue tracking for small teams, inspired by Trello
constructor.dev
TL;DR - we’re building a lightweight-yet-powerful tool that aims to minimize friction and improve clarity for both developers and managers alike, mostly by modeling things differently. We’re aiming for an out-of-the-box experience as simple as Trello, but designed completely from scratch for software teams, with enhancements like threaded comments, blockers, and integrations with GitHub and devops tools. You can take it for a spin with our instant, no-signup demo at https://try.constructor.dev – please let us know what you think!
Really, another tracking tool? Why?
Yes, another tracking tool, because nobody’s done it right yet, not even the recent entrants. We think the friction and complexity everyone hates about tracking tools are largely rooted in flawed models. Dev tracking tools both model the software development process and participate in it, and if they can’t model it in a lightweight way, then their participation adds friction and complexity. This wastes the team’s time and makes management more difficult. For over a decade as an engineering leader I struggled to capture my teams’ run-of-the-mill dev processes in a satisfyingly lightweight way; our solutions were always either inadequately simple or much too complex (Jira) and couldn’t strike a good balance between the needs of management and staying out of the team’s way. We’re building Constructor to solve this problem.
How is Constructor different from other dev tracking tools?
Abstractly: we differ in our product philosophy and our approach to modeling. Concretely: we’re redesigning lots of familiar features in novel ways, for example:
- Comments are threaded, assignable, and resolvable so you can keep discussions in the context of the work, have multiple going at the same time, and keep clutter to a minimum. Most importantly, they provide a lightweight mechanism for keeping track of small ad hoc tasks that might otherwise get lost in Slack, without requiring the overhead of a separate ticket.
- Blockers are first-class objects modeled as free-form text, so anything can be a blocker, not just another ticket – and are built on comment threads so you can easily have discussions around them.
- Checklists are provided for each stage in your workflow. So you can have one checklist for design, a different one for coding, one for QA, one for UAT, etc. We love checklists because they’re flexible and provide a ton of value with a minimum of hassle.
- In the near future, checklist items can be pointers to tickets and thus be used to create completely user-defined work structures. So you can build any structure you like, e.g. milestone -> epic -> story, or have no structure at all. Tickets can be in multiple projects/features/epics at once, since it’s a DAG. This may sound complicated, but we think it will prove to be lightweight and powerful. (And before you say “that’s great for devs but no non-technical PM would ever understand that” – this design was suggested to us by a non-technical PM customer.)
If you’re curious about how we differ in philosophy:
* We view complexity as enemy #1 for software development teams and pursue simplicity with an almost unwholesome zeal.
* We believe a tracking tool should be a great solution for many teams straight out of the box and provide solid value with virtually no configuration or learning curve.
* We don’t think a tracking tool should tell you how you ought to run your team. We don’t buy the idea that there’s one “best process”, certainly not during rapid team growth and change. We think everyone should do what works for their team and adjust it as they grow and circumstances change. It’s Constructor’s job to support that growth and evolution as well as possible.
* We think a tracking tool should never stand in the way of you getting your work done; if you want to do something, you probably have a good reason, and Constructor should let you do it. We can’t stand being blocked by simpleminded validation rules; our approach to consistency checks is more akin to linting.
* Avoid manager footguns. E.g. we’ll probably never report “velocity” even if it’s computed internally because it’s so commonly abused as a dev productivity measure (when in fact there’s no such thing). We know this is in tension with letting teams work however they want, but every rule has its limits.
We have a lot of cool stuff in the works but wanted to get feedback on what we’ve built so far. Please take it for a spin at https://try.constructor.dev and let us know what you think.
Thanks!