[HN Gopher] Show HN: Constructor - simple issue tracking for sma...
___________________________________________________________________
Show HN: Constructor - simple issue tracking for small teams,
inspired by Trello
Hi, we're Seth & Andrew (Aalk4308), founders of Constructor, the
newest contestant in the issue tracking thunderdome. 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!
Author : t3e
Score : 59 points
Date : 2022-02-22 15:20 UTC (7 hours ago)
(HTM) web link (constructor.dev)
(TXT) w3m dump (constructor.dev)
| louky wrote:
| Demo looks great, however when attempting to sign up I get a
| blank screen using Firefox - JS enabled and ublock off, not sure
| why - I'll try a different browser.
| Aalk4308 wrote:
| Strange, sorry about that! While we investigate, feel free to
| shoot us an email at support@constructor.dev if you continue to
| have the issue in another browser.
| iddan wrote:
| How is this better than Linear? Been using it for a while and I'm
| pretty convinced it solves the problem space perfectly.
| t3e wrote:
| Linear's a _great_ step forward but too prescriptive and still
| too heavyweight for lots of teams. Our focus is on dramatically
| simplifying, and aligning the core conceptual models with how
| teams actually want to work, e.g. threaded comments, flexible
| blockers, user-defined work structures, etc.
| csunbird wrote:
| hey, I think that you are now also allowed to put down an opening
| post along with your link in Show HN threads.
| beingflo wrote:
| Absolutely love this! The design language and focus on simplicity
| is right up my alley. If there isn't any blocker (pun intended)
| that I'll only come across later this will definitely replace
| Todoist for me. 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. 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?
| Aalk4308 wrote:
| > Absolutely love this! The design language and focus on
| simplicity is right up my alley.
|
| 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.
| beingflo wrote:
| > 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.
|
| Love to hear it! I'll remind myself to give feedback in
| return.
| [deleted]
| aparsons wrote:
| Thanks for sharing. I love the design and how this app feels. Did
| you use any existing CSS library/framework or is everything "hand
| crafted"?
| Aalk4308 wrote:
| Thanks! All of our core UI components (e.g., buttons, text
| inputs, etc.) are "hand crafted". We do use
| https://blueprintjs.com/ for some components, but we apply our
| own styling on top.
| zeptonix wrote:
| Looks great and super smart to have the instant demo. More SAAS
| tools should offer that.
|
| 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!
| t3e wrote:
| Thank you for the feedback!
| pqb wrote:
| > 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!
|
| 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!
| t3e wrote:
| Thanks! We have the exact same complaints, and that's why we
| invested so much effort in this approach. I think a lot of
| companies would never do this because they'd fear adversely
| impacting their conversions metric, but our goal is to just get
| people to understand our product as quickly and easily as
| possible and hopefully get feedback.
|
| 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.
| steviedotboston wrote:
| Nice! Is there only a kanban style view, or is there a way to get
| a list view as well?
| t3e wrote:
| No list view yet, but it's on our roadmap!
| phphphphp wrote:
| I think this looks great but "process-neutral" gives me pause.
| Process is important, and hard, and in practice "process-neutral"
| means "process by committee within each customers organisation"
| and naturally, that committee probably hasn't designed a great
| process before and so they're going to end up designing a subpar
| process... and for people subjected to that process, it'll
| reflect on your software.
|
| 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.
| t3e wrote:
| Thank you for this thoughtful comment, I'm happy somebody
| challenged us on this controversial point of our philosophy.
|
| 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.
| drcongo wrote:
| Hello, this is possibly relevant to my interests but I can't
| quite tell. We have a couple of requirements from an issue
| tracker and I've yet to find any service that meets them.
|
| 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.
| yamazakiwi wrote:
| We're using an app we built internally in a similar fashion
| with clients having access to the boards.
|
| We were spun off a consultancy and use it with all our
| consultants clients.
|
| PM me for more information!
| t3e wrote:
| Hi, thanks for your feedback and questions.
|
| 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/
| drcongo wrote:
| Thanks for the response, this definitely sounds like one to
| keep an eye on then! Congrats on the launch and look forward
| to seeing where you take it.
| thedangler wrote:
| Can't sign up. Get an error and it tells me to contact support.
| t3e wrote:
| Thank you, we see the error and are investigating.
|
| Edit: fixed now, JWT token issue with Auth0.
| airstrike wrote:
| As much as I like developing software, I sort of wish these tools
| existed outside of the software use case. It seems like 80% of
| the concept can be repurposed for other types of team
| collaboration and I'm not sure how well that market is served
| obilgic wrote:
| hyper specialized software is often not necessary; hence excel
| and trello.
| airstrike wrote:
| Agreed, which is why I'm advocating for a less-specialized
| version of this software
| t3e wrote:
| We don't disagree and we've heard from non-technical
| managers and designers that Constructor has the potential
| to be simply "a better Trello for everyone". This is
| probably because despite being designed for software teams
| we try to serve all roles equally well, i.e. make sure we
| create an outstanding UX for the non-developers on those
| teams. Something we've seen happen at a lot of places is a
| "tool schism" where part of the team (design or PM) will
| cleave off and use Trello or Basecamp and leave the devs to
| Jira because they find it unusable, but the devs need their
| Jira for various good reasons. Constructor is designed to
| prevent tool schisms.
|
| 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.
| long_time_gone wrote:
| I love this comment. For example, I have yet to find a tool
| that helps teams manage worker leave (medical, parental, mental
| health, etc.). A way to quickly get a co-worker up-to-speed on
| your projects before you take leave; a place to document the
| calls, check-ins, etc. while you are out; and board to manage
| tasks upon your return.
| andylynch wrote:
| They do but it's hard to gauge how widely, in part I think
| because folks doing those things are less likely to blog /post
| about it. But for example in a past role I set up Jira for a
| non-IT team in a national museum, and a colleague did the same
| to help a supermarket chain develop new products.
| thedangler wrote:
| I work for a University, our little rouge group of devs are
| looking for something right now to try. Would we fall under non-
| profit/ educational?
| t3e wrote:
| Definitely!
| helixc wrote:
| We're Constructor customer, and use it to manage our open source
| projects. It's fast and simple, and does all we want.
|
| 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)
| t3e wrote:
| Thanks, Helin! Very happy to hear I've been helpful; I'll go
| ahead and add myself to our features comparison page.
| moodini wrote:
| Currently testing all kinds of tracking / ticketing software.
| This one looks really good, I love the simplicity. The design is
| superb. Congratulations!
|
| 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.
| t3e wrote:
| Thanks for the feedback!
|
| - 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?
| bachmeier wrote:
| This is really nice. Hope you don't add any additional features.
| t3e wrote:
| Thank you for the feedback, and I completely understand and
| share this sentiment. We're very cautious when adding new
| features and are obsessed with keeping the out-of-the-box
| experience utterly simple and tuned to exactly what a small
| team needs. It's a major design consideration for us that as
| much as possible, complexity is opt-in.
___________________________________________________________________
(page generated 2022-02-22 23:01 UTC)