First, congratulations on launching. I think people are so used to seeing beautiful products these days that it can be hard to remember how hard it is to make anything. Nice work! With that out of the way, here is some critical feedback:
- 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.
> Linear (whose design language you seem to have ripped off, somewhat poorly.)
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. 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.
> Keeping our love aside we believe the building of a marketplace for agents/integrations is where the community can help us a ton.
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.
Hey, we are still early and are figuring out things. Thanks for being candid, was there something you are interested in seeing in the product? (use case, feature etc)
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.
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
Note that “open-source” does not imply anything about quality, or your entitlement to that. As was already noted they’re selling access to a cloud product that you are entirely welcome to use if you do not want to think about how the code works.
Calling something open source to get traction doesn't entitle a project to much anymore, too. Gone was the time that open source was synonymous of creating public software while building a community. What we see here on Show HNs is pure marketing strategy.
> Look at all the environment variables in this dockerfile — which ones are necessary to run this service myself?
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.
- 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.