We've actually done test on scaling. This is a fork of Linen.dev which had community of up to 50k members. So we've tested this well. Search is an on going feature we are working on. We're going to enhance it with more embedding like search functionality.
Definitely agree on developer community and third party integrations. That is our main focus after this launch. Building just a good quality chat tool took quite a bit of time but we understand how important the dev ecosystem is.
Thanks for checking the privacy policy will update to include AWS!
One of the pain point I've actually seen for Slack is Slack Connect becomes disorganized very quickly to the point where you need a custom solution to manage it. I think it is a symptom of the overall problem with Slack. Since Linen is thread first it makes manage these conversations much easier. We do plan on shipping our own version of Slack Connect or even integrating with existing channels.
Pricing wise we're still figuring out. I do think paying for active users is a likely direction though!
One thing that we wanted to do was to create a design that was more modern and a bit more familiar to the average Slack/Discord user. I think zulip is great but can be a bit more overwhelming. We wanted to keep a familiar UX as much as possible while giving the benefits of a thread first experience.
Secondly we are a bit more opinionated in thread management. Our inbox is designed to get to an inbox zero state. We have things like !mention vs @mention which helps with urgent vs non urgent communication.
Some technical notes:
This is actually a fork of Linen.dev, an SEO-friendly Slack alternative for communities. We originally built Linen.dev with Next.js but ultimately found it quite limiting when we wanted to make things fast and responsive and have custom caches. For Linen.team, there wasn’t a need for server rendering since we didn’t need our product to be SEO-friendly. We removed Next.js and replaced it with Vite and Express, which simplified our code quite a bit since we didn’t have the legacy requirements. We also spent quite a bit of time optimizing the performance and query so that it is much faster than the previous version of Linen. Our plan is to open source Linen.team as well; we need to do some repo clean-up first.
Finally, after a year, we actually reduced our client bundle size from 500kb to less than 400kb. You can see our post on bundle optimization here: https://news.ycombinator.com/item?id=35718417.
Tangentially related, and agree with the complexity and churn that Next introduces, but curious: If am building a product where SEO matters, does SEO still really suffer in absence of SSR?
Sure TTFB (& potentially other web vitals) are better with SSR, but I still keep hearing SEO friendliness as a primary reason for SSR though prevalent crawlers like Google/Bing can index js loaded content.
> Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines. Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution.
> Crawlers may understand JavaScript, but there are often limitations worth being aware of in how they render. Client-side rendering can work, but often not without additional testing and leg-work.
It's a restful api that doesn't hold any state, we use jwt (jsonwebtoken) for auth. It's essentially a collection of routers for different actions. Mostly crud, with few exceptions like webhooks, auth flow. We often use middlewares e.g. for things like validation. Everything is written in ts/tsx so the client/server do share types. We serialize data to use it in a standarized/known format in the UI.
If you like the middleware system in express you might be interested in starfx, which implements the same middleware but for fetching and data synchronization in the FE. It has a simple but powerful state management system and leverages structured concurrency to manage side effects.
The problem is maintenance of a separate database and operationally it would be more work. For us who want to use embedding features having a separate database just for the embedding means now we have to keep data across multiple databases in sync and to maintain
Linen.dev founder here. Linen is a Google searchable community chat platform. Most of our communities use us to make Slack/Discord Google-searchable.
We've had users ask about making Matrix Google searchable. This is a beta version of the feature and lacks a lot of the features as our other integrations. We currently support two way real-time text sync between Matrix and Linen. In the roadmap we have historic sync, images, emojis and users sync.
Would love to hear some feedback and if this use case makes sense.
3. "You have to focus on large markets with many (or large) customers"
Yes you shouldn't take VC money if you don't want to go big eventually.
4. "Making existing customers happy is less important than acquiring many more new customers"
You have to do both and the goal should be to make existing customers so happy that tell others which will drive growth. If you don't make a product people love you won't win in the long run anyways.
Finally I think a common mistakes for Founders is making their VC's their boss. Although I agree with some of the sentiment of there is some perverse incentives with VCs as a founder you should take ownership of the decisions that impact your company.
That list sounds right I think their is nuance for this one
>3. "You have to focus on large markets with many (or large) customers"
>Yes you shouldn't take VC money if you don't want to go big eventually.
One can want to grow to a point of organically understanding the problem domain before going big.
The VC and the company may differ on the short term but agree on the long term.
Which is a distraction. If the company is doing everything else suggested and the VC pounds on this issue.
I would think the ideal time frame for the use of VC funds is probably about 2 years. If the company can't make productive use of the funds and return it in 2 years the timing of the funding is bad. If funding is needed for some large capital expenditure that will depreciate over decades should have existing revenue support.
I think Wall Street has created a different industry that is a business model of its own fantasy.
