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 gettin...
47 comments
[ 3.2 ms ] story [ 90.8 ms ] threadEdit: fixed now, JWT token issue with Auth0.
Your 80% observation is if anything an underestimate; there's almost nothing in Constructor that makes it dev-specific beyond the GitHub and devops integrations that are mostly absent if you don't activate them, and would be easy for us to make totally optional. This surprised us when we realized it, because we are quite devoted to serving software teams specifically.
Jira / Atlassian / etc. does my head in every time I even have to login, let alone use it.
Hope this tool / ones like it will take off!
1. We need to give clients access, and we need to give those clients fairly fine grained control - ie: This user can see the tickets, move them around, comment etc. but not close them. On some projects we have lots of people on the client side that want to be able to see the tickets, so we very much don't want to have to pay per user for client access. For many reasons, giving them GitHub access is not ideal, but the biggest reason is that GitHub's permissions model on issues is, at best, bizarre.
2. I got quite excited when I saw the words "bidirectional GitHub integration" on the home page, but then I read the description underneath and I'm having a really hard time picturing what it does. We like adding ticket numbers to commits, because that keeps a reference to the change that was made in the ticket thread on GitHub. Other devs coming in can easily read the thread and click through to see the change. Your description of the GitHub integration seems very focussed on PRs rather than tickets, and the way we work a PR is most likely to contain many, many commits, and multiple tickets.
1. We have something in this direction already in the form of "guest users" that can be added to your boards and don't count as a seat. They currently have full privileges on the boards they can see, though – our permissions model isn't fine-grained yet.
2. Sounds like we may need to improve our description of this feature, but right now, we're optimizing for small-PR "trunk-based dev" [1] workflows where a ticket can have several PRs, but a PR always maps to a single ticket. We push the ticket info onto PRs in GitHub so code reviewers don't even have to click through to Constructor to get the context they need to do their review. We'll definitely support use cases like yours in the future, though!
1. https://trunkbaseddevelopment.com/
We were spun off a consultancy and use it with all our consultants clients.
PM me for more information!
I love it! I wish more SaaS will provide such abstraction for users who only want a preview of all features. I find silly trial periods a quite waste of resources (storage, mailing cost etc.). When I am testing a new product I use test/fake data (e.g. temporal/masked e-mail address) and there is near-zero chance I will convert to paid account with it. I would rather create new account to drop all testing history behind me.
Congratulations, and I hope you will cut some pie from this crazy Jira-like-software market cake!
We also really don't like product tours that lock you into an endless sequence of modals, so we came up with this "overlay" that users can turn on and off, inspired by museum audio guides you can hold up to your ear whenever you like, or ignore entirely.
For example, Jira isn't itself bad, Jira is quite nice in a vacuum, but Jira in the hands of an organisation is a nightmare because of the incoherent methods of working layered on top of it by well meaning but inexperienced process administrators who think configuring Jira is the solution to every delivery challenge faced in their org.
I've worked at half a dozen places I can think of off the top of my head where they've excitedly jumped into using a new (to them) issue tracking product, everyone loved it because it was new and exciting and empty and solved a problem... for a few months, and then people grew to hate it because it becomes an esoteric mess again. For example, Trello -> Notion -> Coda in the space of 18 months.
The decision to be process-neutral is a valid one and can be a very powerful foundation of a product, so my question is: do you have any specific thoughts around how you're going to be process-neutral while also stay loyal to the commitments you've made to being pleasant to use? If you can achieve that, a product that doesn't reflect the bad choices of administrators, I think you have incredible potential.
I disagree that a tool being process neutral implies anything about how the process ends up being designed, e.g. “process by committee within each customers organisation”, other than it won’t be decided by the tool. Process neutrality removes a set of constraints that in our experience add a lot of friction when teams want to work differently (and makes designing a great UX harder because of combinatorics).
There are indisputably tons of teams that seek and benefit from process guidance, including the ones I’ve run, but we think that should come from mentors, books, blogs, etc. – not the tool.
I agree that a lot of issues in Jira stem from wretched implementations, but I lay the blame for those implementations squarely at the feet of Jira. If most of the programs written in a language were impenetrable and borderline non-functional, would you blame the users, or the language?
Our biggest beef with prescriptivism in tools is that it impedes exploration and evolution of process changes that we feel are important to teams adapting well to growth and changing circumstances. It’s a much harder proposition to build a flexible tool, but we feel it’s necessary for this reason.
For my use case, list views are a must-have. You commented that such feature is on your roadmap. Are you planning to include configurable sorting, like: - list all items per user - list all items per label - list all prio 1 items
Also I could'nt find a way to prioritize tickets.
Are you planning to make the tickets searchable (eg. list all tickets which include the word 'onboarding')?
Will there be a "language add-on"? Some of our customers would need to have access, but rather would like to navigate in their native langauge.
- List view is on the roadmap but not designed yet; we'd love to understand your needs in more detail if you'd be up for dropping us a line at research@constructor.dev.
- By prioritize I presume you mean set an absolute priority? Priority right now is explicit in the ordering of tickets within their respective columns, but it's relative, not absolute. We're open to adding absolute priorities.
- You can search tickets with the search in the navbar, or filter the board to show a subset of tickets with the filter box.
- We haven't embarked on i18n/L10n yet but it's just a matter of prioritization – what language(s) do you require?
In addition to all that, the founding team, esp. Seth, is a hidden feature! Every time I feel our team needs some extra functions, I book a time and talk to Seth. He asks very deep questions about our work flow and pain points. Some of the questions even helped me to reflect on our way of doing things, so we could use the opportunity to evolve.
(edit: fixed typos)
Thanks for the compliment! We did put a lot of thinking and attention to detail into our design language.
> Are there any restrictions on the free plan? I'd be more than willing to pay a reasonable fee to make the "single-person-plan" sustainable without the need to restrict it in the future.
Nope, there are no restrictions, and we don't intend for there to be in the future. The free plan is 100% fully-featured with no difference versus the paid plan aside from the limit on the size of your team.
> Also, one thing that I notice in the demo is a flurry of requests triggered on just about any user activity. Is this just extra analytics in the demo or is this also present in the full app?
There's no difference between the demo and the full app. You're right that some of what you're seeing is for analytics. There's also admittedly more network chatter than we'd like to keep the frontend synchronized with the backend, but we actually have work already in progress to reduce that substantially.
Love to hear it! I'll remind myself to give feedback in return.
However, every platform in this market tries to solve a similar problem in a different way but I think no one tries to solve the biggest problem.
That problem is that there will be one or two people that really care about all of this tracking stuff but everyone else just don't. Developers don't need to check tracking tools everyday to know what they need to do and once they finish, they will not update the tracker. So when the people that cares check the tracker, it doesn't give them the latest info.
So the problem with tracking software is that it requires everyone to use it the way it was meant to be used, but employees just wanna do the 8 hours and go home and not care who is on what page.
Like `if (inputsNotHandled) _sendToJira(“issue is not resolved”)`
But that’s probably not easy to do in most cases…
This is an awesome point, and one which we're keenly aware of. This is how we think about this:
Constructor must serve different roles with their own notions of success, and those notions may be at odds. That is, there are some tensions and tradeoffs within teams that exist independently of any tool, e.g., managers want stuff reported but developers just want to build software and not fill out TPS reports.
So our approach to solving your biggest problem is to try to create the best UX for each role, period, which implies Constructor must mediate these tensions where possible. For instance, our approach to blockers is very lightweight and we saw immediate uptake from devs when this was released, indicating they saw it as a help, not a burden. And of course it makes it apparent to managers what's going on without having to pester anyone. So we consider this a feature that helped both managers and devs do their jobs better without imposing an unwelcome burden on anyone. We're looking to extend this pattern in much more clever ways to get managers the facts they need without burdening developers with housekeeping tasks to provide those facts. It's a tough problem but we're optimistic we can make headway here.
Thanks for raising this point; it's really, really important.
I also hate Atlassian, so I was super happy to see such a nice alternative.
Tried the demo from desktop, looks like the perfect alternative. Loaded in on the mobile to see if it works there... "Sorry, this demo requires a desktop-sized screen."
oof
Is that just the demo, or a real limitation?
Curious how you've thought of positioning yourself -- what's a typical team look like that should pick your tool? How long have you been building this? How do you convince teams to pick you over say Linear (one of the new darlings)?
It would be great to hear some of the backstory!
Our differentiator is lightweight flexibility, supported by conceptual models that reflect reality and don't impose one particular way of doing things on teams. Our goal is for teams to be able to "start simple and evolve easily" because for many teams their process is always being adjusted as they grow and mature. Our approach is essentially "Trello is like 90% of what many teams need, let's redesign it from the ground up for software teams and get it to 100%". It's early days but it's an approach that seems to resonate with many teams. At least partly this is because PMs and designers readily understand Constructor instead of being annoyed/overwhelmed, so everyone is happy using the same tool, and that's pretty important (to avoid tool schisms).