Email: elon@xyz.com
Password: XfFNw6GwVJVQv6PA
With the rise of LLMs, we thought about how project management and issue tracking would look 5-10 years from now. The current tools didn't match our vision, which excited us and started the journey of Tegon. We aim to build a tool where manual workflows are either automated or handled by AI. This tool will provide better context about a task to an engineer by smartly gathering data from all sources, helping teams with better prioritization.
Tegon loads all the data from local (indexed db) thus making it super fast to load and navigate. We make all of this happen by real-time sync in the background. Tegon also uses AI to simplify the issue-creation process by automatically creating titles, suggesting labels and assignees and identifying duplicates. Tegon also simplifies the issue creation process from Slack, just apply an emoji to a Slack message and a tegon issue will be created making it easier for other teams to raise bugs or feature requests to engineering teams.
We deeply value the feedback from this community and have spent the last month revamping Tegon's design based on the feedback from our last launch. We just got started and there's a lot more to come. We're eager to get more feedback and keep building. Let us know what you think in the comments :)
I have to guess /hope that they did this already; who would make a time investment like this without first proving that the product has value? Anyway I certainly wouldn’t even pilot it without some proof.
Additionally, incorporating agents and managing their workflows require a distinct set of metadata and separate workflows, which we are still in the process of exploring.
If you have an API to manage issues, that could work as well. Would need that anyway for custom build integration etc.
Edit: Never mind, found the list you posted elsewhere.
Someone else's mystery machine is fine for a start, but if you want to train and test (and validate) your assumptions or do your own experiments, these AI features don't offer much.
- What is the pitch that you made to YC that convinced them to back you? The market size just doesn't seem that large and I don't understand what will differentiate you from Linear (whose design language you seem to have ripped off, somewhat poorly.) This post and the current featureset is vague and does not seem like a significant improvement. What is the core problem you're solving and why is that valuable? Your launch post above describes a lot of "how" but not a lot of "why".
- Why are you bothering to pretend to be "open source"? You're backed by YC and you'll make money selling access to the product on your "Tegon Cloud". If you're really going to be open-source, you need to make some significant improvements before anyone would consider contributing. Some documentation on how to self-host would be a good start. Look at all the environment variables in this dockerfile — which ones are necessary to run this service myself? https://github.com/tegonhq/tegon/blob/main/docker-compose.ya...
- If you're going to be "open source", the quality of your codebase and engineering skills is going to be a deciding factor in whether or not you get outside contributors. Consider writing actual descriptions in your pull requests, describing what you've done and why. Here's a PR picked at random — this is bad engineering work and does not encourage others to contribute. https://github.com/tegonhq/tegon/pull/114
My advice is that you drop the facade of being "open source", hire a designer, and do some actual user research to figure out where people are actually struggling with their ticketing systems. The features you're building (automatic title suggestion, thread summarization, and "find similar tickets") do not solve the problems that I have had with ticketing systems. They're small, potentially nice-to-have features that absolutely do not help me understand the core question for all engineering teams: who is doing what, how will they do it, why, and when will it be done.
I thought I recognised the name. When it was first posted to HN[1] it was repeatedly criticised -- and seemingly flagged to death -- for being a carbon copy of Linear's design. After that the screenshots were removed from the repo with a "We are redesigning our product" notice[2] until this design was released ~3 weeks ago[3].
Good on them for trying to redesign -- I think it's good that they gave it a shot -- but it does still look quite similar.
[1] https://news.ycombinator.com/item?id=40290735 (https://archive.is/Yd010)
[2] https://github.com/tegonhq/tegon/commit/4887ac7e678197f77243... (https://archive.is/MGHeF)
[3] https://github.com/tegonhq/tegon/commit/dafb4337f6a446dba328... (https://archive.is/ABXYk)
1. We started our documentation at https://docs.tegon.ai, though it is not ready yet points taken, and we will work towards making more documentation.
2. We are planning internally to bring more systems to how we manage PRs and to have the right information on them.
3. We love opensource and we have built all our previous products opensource. Keeping our love aside we believe the building of a marketplace for agents/integrations is where the community can help us a ton. We are currently working on making that more modular so that people can start contributing.
What we have done till now started with the basic Project management and there is a lot more to be built and to solve.
You wanna customers that act like salesman. Who doesn't? What the community can help you with doesn't seem to align with what you can help the community with.
https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...
Separately, there seems to be a ton of unused or broken or dead code sprinkled throughout — for instance, in the auth code, I can't tell if you're doing basic email/password auth or using Supertokens and a third-party login via Google. You have code for both and some routes seem dead or missing.
https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...
Also, I mentioned the lack of documentation for how to run Tegon locally because your docs are entirely insufficient. The main docs page is just a README template. https://github.com/tegonhq/tegon/tree/main/docs
The quickstart guide has a broken link to instructions on how to self-host https://github.com/tegonhq/tegon/blob/main/docs/quickstart.m...
The oss/local-setup guide is entirely empty https://github.com/tegonhq/tegon/blob/main/docs/oss/local-se...
The oss/deploy-tegon guide does not explain anything and the script it references seems out of date https://github.com/tegonhq/tegon/blob/main/docs/oss/deploy-t...
I'm done looking at this project. I strongly recommend hiring the best engineer you can find as quickly as you can.
Noted. We will work on it.
Yes, we use Supertokens and we support email/password and google auth. Google auth is something we added recently as that was requested.
It would also help to sort and de-duplicate the variables in the file. COHERE_API_KEY is listed twice. Adding a comment per block of API keys on what they're for would also be nice.
I realize AI is the hype right now and it seems like most products have to pay the AI Tax (i.e. "Yes we're doing AI stuff so you should <buy/sell/fund/etc> our stuff"). But "AI" is a nebulous category, and when a product bills itself as "<Noun>-first", it sets up an expectation that <Noun> is fundamental to the product, i.e. if you stripped all other aspects of the product away, what's left at the end is <Noun>. But I have no idea what that means in the context of the current "AI" hype.
Based on your demos, you've built a fairly standard looking ticket tracking tool that has some AI features. And those are features that every incumbent in this space started adding to their products years ago or are actively doing it now.
I mention this not because I'm trying to say your product doesn't have value, but because the way you're positioning this doesn't make a lot of sense to me. As a prospective buyer, if I'm already using an existing tool, the moment I start digging deeper to know what "AI First" means, I'll find that what this really means is "Jira but with some AI features on top", which isn't very compelling when my <Vendor> account team has been telling me all about their new AI features that I can start using on all of my existing data as soon as I upgrade, no 6-18 month migration required.
If I'm a frustrated customer of those products, AI is not the reason I'll be looking to switch, and I'd be far more likely to be interested in performance, extensibility, openness, integration capabilities, etc.
Maybe that's not the type of customer you intend to target, but if you hope to reach them, I leave this as food for thought. Best of luck to you.
Oh, the AI hype! It's basically just common sense wrapped in a shiny new package.
Let's call quick filters 'AI' and be amazed, shall we?
When the dataset is limited, what magical tricks can AI pull? Joining threads or conversations is just a fancy wildcard search. Where's the real optimization?
i am a zero-to-one guy and i get that this kind of positioning is often forward-looking, but i think that's what early-stage founders get wrong, especially if they aren't core whatever-noun they are anchoring to.
if you consider all other incumbents in this space, they are all AI-driven. your differentiator could be AI only if you are core AI and have drawn up models for project or work management use cases. otherwise, just stick to whatever your differentiators are in the near-term and change positioning later when you are core AI.
Taskade did this well. Notion is doing it well. they are all pivoting around AI without trading off whatever's their core.
Sounds like this is what they should be asking you more about.
Would you mind rattling off some a wish list?
Perf I can imagine but some of the others not so much in detail.
Maybe not a 6-18 month migration, but you will have a similar wait for Atlassian to deliver something approaching functional.
Of course this doesn’t matter to the leaders that can now claim their ticket tracking is AI enhanced, but the net value of the feature at that time is negative or zero.
Otherwise I agree though. Frustrated Atlassian customers do not move because they really wanted AI.
1. Ensuring ticket has enough information 2. Offloading some amount task before someone picks it.
These are the 2 key areas we are focusing and we will launch some features around these in the coming weeks. Would love to hear if there are some other places you feel we can focus on?
Copious amounts of gratuitous hallucinations contaminating the data you are looking to work with.
We value input from the community and are open to suggestions and assistance in making this decision. Our goal is to prevent unauthorized copying and resale of our product under different names while fostering a collaborative and innovative environment.
There's also the BSL. It specifically calls out competitive products. It automatically falls away for code older than a given time to another OSI license: https://en.wikipedia.org/wiki/Business_Source_License. Per the Wikipedia article this still has issues: contributors are handing over their work for to you for free for that duration, they can't use their own work for profit.
The AGPL does make your project extremely unattractive to competition, without affecting your contributors. The issue is that it is still possible to compete with you using it, so long as your competition releases all their code (i.e. infra, billing, etc.) under AGPL.
I would personally go for AGPL because it will keep the worst offenders (Amazon, Microsoft) away from your code.
1. Open (Source) for Business: A Practical Guide to Open Source Software Licensing
2. From Project to Profit: How to Build a Business Around Your Open Source Project
This video presentation by her on this topic is really valuable too: https://www.youtube.com/watch?v=Ck1gJIZ3Lr4
You will then have a really good idea of where to start. As the parent poster said, it is wise to switch to AGPL if you want to build a COSS business.
If you want to compete on being open source your license has to be free.
The server is written in Node.JS
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?
I would've been interested in an actual replacement for Jira/Linear, but I'm uninterested in an unreliable tool where I have to deal with hallucinations. Stop trying to cram this crap into every single software project.
Our approach, however, is AI-first. We are focused on integrating multiple AI agents into our tool to assist stakeholders in various ways, including automating manual tasks, providing enhanced context, and even resolving issues end-to-end. Our goal is to leverage AI to significantly boost productivity and streamline workflows for our users.
Right now, we’re using the product ourselves and trying it out with a few customers. We’ve noticed that for simple placeholder tasks, a straightforward title works just fine. But for more detailed tasks with longer descriptions, the auto-generated titles seem to work better. We’re still experimenting and gathering feedback to make it even better.
Examples from our board:
Description: - utils.py 228 : Failed to call LLM with the following error: BedrockException Invalid Authentication - An error occurred (UnrecognizedClientException) when calling the InvokeModel operation: The security token included in the request is invalid.
Title: Feat: Investigate Salesforce cloud version error: Invalid Authentication
Description: Triage ux bug - once i decline or accept a triage request, it re-directs me to issues screen. Ideal behaviour to be at the triage list view where you either show removing it from triage or highlighting that an action have been taken on this request.
Title: Redirect user to Triage List after Accepting/Declining Request
Isn't this "wrinkly" technical detail lost?
- "AI-first"? What does that even mean? Calling some API to auto-generate a title? Do you really think that a) this solves a big user problem and b) that Linear can't add that in two seconds if they wanted to?
- Open-source and VC-backed? Please stop bull shitting me, and yourself.
- What is your USP? That you're faster than Jira? Fine, but this is not 10 years ago and snappy tools like Linear exist (and I'm not even a fan of Linear).
- elon@xyz.com? Really?
Please use your time and talent for something else than this VC AI pipedream. Or don't, I'm just a rando on HN.
FYI Linear has had this feature for a while. It works quite well.
1. Context enricher - To ensure the ticket has enough information 2. AI agents - To offload some part of the work.
We will be getting these out soon
Cohere: To improve smart delegation, duplicate detection, and automated triaging, we integrate Cohere's advanced NLP capabilities, ensuring more accurate and efficient similar issue searches.
We are bringing in more agents to delegate some of the work to them. 1. Code agent: This will help you in solving the small code fixes and small features but assigning issues to the agent and giving it instructions on how to solve them. 2. PRD agent: To help in PRD writing for the PM
we'll add more agents for different use-cases going forward
Was curious if the AI could assist them in a useful way. Sometimes they might poorly explain the problem, which module it pertains to or similar or similar, making it very unclear what exactly the issue is.
I was thinking perhaps an AI component that could analyze what they said and "complain" if the AI detects key information is lacking, or perhaps just re-summarize what they wrote so it becomes more clear when they haven't supplied sufficient information.
[1] https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...
[2] https://github.com/tegonhq/tegon/blob/158b54af8d6f7cf4195c61...
Happy to create an account for you to try it out. harshith [@] tegon.ai
We will also explore more to see if there is a better way to do this.