Hacker News Reader

Comment by CapeTheory | Hacker News Reader

IMO the absolute most important thing with a tool like this is performance. I have to sign in to a handful of cloud desktops each week and interact with customer Jira/Confluence/AzureDevOps/etc pages, and the big thing which kills my engagement is the app not being snappy enough. Doesn't matter how many of the features our Agile SAFe scrum wizard wants me to use, I'm not going to bother if there is too much friction. These apps inevitably require a lot of clicks, so latency becomes very noticeable.

View on HN

True performance is our priority. From the very beginning, we focused on ensuring that our app ran smoothly and quickly. To achieve this, we load all the data locally, allowing you to experience everything at lightning speed. Our background server keeps your data synchronized seamlessly between the server and the client, so you get the best of both worlds: speed and reliability.

> True performance is our top priority

The server is written in Node.JS

My bad. We focused on the performance on the front end currently, as said before we loaded all the data locally and kept the data synced in the background to make the interactions fast. We chose nodejs as that was easy for us to get started with. But definitely, if things get hampered we will start looking into it.

Good call. Front-end performance is often the bottleneck. Preloading most of the required data in advance is really helpful. Trello does just that and it is one of the snappiest web apps.

Node is capable of significantly better performance than the average Jira instance.

The bar is low.

That is entirely orthagonal to the issue. NodeJS can be Fast.

We are also working on a more chat-based approach to interact with the tool. To let you directly handle things from the messaging tools like slack.

I completely agree. I've often found myself copy pasting links to slack threads or screenshotting messages to append to tickets. being about to flag a thread and have a service create a ticket, summarize the discussion, highlight the requirements, and (importantly) include the things we decided against doing, would make life so much easier.

the flip side of course is that the easier it is to create a ticket, the easier it is to create duplicate or contradictory tickets. does your system offer the ability to check for existing tickets that are a close match for whatever is being created?

Hey, that's where we bring in triage grouping and duplicate identification. We show you what are the similar issues and we are also working on smart merging so to merge the information from both the issues.

Reply on news.ycombinator.com