Launch HN: Slite (YC W18) – Note App for Teams

An active user from Russia here :). We are a small team of seven developers and we already love Slite.

Before Slite we were using multiple Google Docs and Sheets files to manage our team notes, and Trello to write down decisions we made during team meetings. We would create a lot of files on Google and send links to each other using Telegram or email. It's OK if you don't have a lot of documents but after a few months of working it's became a pain in the ass to find some particular file (and it's actual, team-approved version).

On Trello we had this 'Notes' board, where we would put all the notes on product decisions and team meetings, but it quickly became overloaded with stuff and you would hardly find anything there.

That's why our team loved Slite so much. It's very simple yet powerful tool. I am not sure if there anything else like that. Probably yes. But we are absolutely satisfied with Slite and like that its team already reached out to us to gather our feedback :).

Data, is my guess. Existing note apps perhaps don't collect, package, and act on (sell) that data as well as they could. I would not be surprised if that's a major component of any new company that just looks to be re-hashing existing companies. Their "new" approach is an improved UI, and massive data collection.

Unfortunately, as far as I'm concerned, none of these (or any existing note-taking app that I've tried) hits the sweet spot for me. I've commented on several note-taking apps in the past -- quite enthusiastically -- and I'd really like to see more.

For some background, I live and die by my notes. Mainly due to spending about a decade developing against an obscure set of APIs that were poorly documented, and that Google proved somewhat worthless for, I ended up creating a rather large library of code snippets and documentation around corner cases with three specific APIs. Over time, I started documenting other things. We've all ran into that case where we search for a solution to a problem, find 70 different answers, 68 of which are somewhere between OK and awful, two of which fix the "corner-case". You fix it and move on only to encounter it again a few months/years down the road -- only this time, the bookmark is dead. So you spend an hour crafting ever-more-elaborate search queries[0] to surface something resembling those two, good, solutions. I've always got my note-editor open and the format is so quick to work with that I started documenting those, as well. Yeah, the best coarse of action would be for me to put this out on my blog, and I do put the really interesting (to me) ones out there, but I don't have time to do that every time I need to write a note.

I am also, routinely, put on projects for the purpose of analyzing an existing, large code-base and proposing improvements. This results in several-hundred printed pages of notes which serve as a map of the project. After proposing improvements, I'm usually one of the folks (or the only 'folk') involved in implementing them. Having a simple, low-overhead way of handling this sort of thing is critical.

For my particularly narrow circumstances[1], all of the note-keeping/note-taking tools out there are somewhere between tolerable and terrible. We use Confluence at my office -- I hate it. The WYSIWYG interface works as well as Word[2]. There's a Markdown plug-in, but the resulting document has the Markdown parts wrapped within the plug-in and it doesn't look right. I also have little control over how the Markdown is rendered other than some baked-in tempaltes. I like a well formatted document[3]; Markdown lets me communicate that formatting effortlessly and explicitly. It looks good in the console (often better than a non-Markdown text-file if you use a linter-enabled editor). I store my notes in a git repository, which I now sync via keybase.io's encrypted git. This lets me keep my notes on an encrypted volume, complete with semi-sensitive information (and git-secrets for passwords/IDs and such), and store it end-to-end encrypted somewhere else for when my drive inevitably fails, and I can keep a copy of my notes on every machine I use. Most importantly, though ... getting information out of my notes involves "grep -R 'expression' (star)", and it screams on an SSD. With the addition of a -B or -A, I rarely have to actually open the document to find the answer I need.

Generally speaking, I use VSCode on Linux with the (excellent) Markdown Enhanced Preview extension to take most of my notes, or 'vim'. One or both of these is open at all times on my development machines. I generally use VSCode because I like a live-preview of what I'm writing, despite not wanting a WYSIWYG editor. No. Please, God No[2-again!].

My ideal solution would be self-hosted (I'm open to cloud-hosted if it's end-to-end encrypted and reasonably priced), git-backed or at least offering a way for me to clone ... everything, Markdown+Highlight.js-baesd with templates that can be customized and applied per-document or per-task. There are a few out there that come close. I've tried several and am currently setting up Realms-Wiki in a set of docker containers -- as I write this -- it looks like it covers enough of what I need that it may just work. Collaborative editing would be a nice-to-have, but it's way more important to me to be able to just use 'git' rather than have fancy ether-pad like functionality[4]. Unfortunately, after looking over Slite, it doesn't look like it fits well for me. I couldn't find anything regarding Markdown support, which -- even if it had a perfect WYSIWYG interface, minimally means having to convert my existing library. It looks like the target audience is Confluence users who are as dissatisfied with the product as I am, but for different reasons.

I'm certainly not crapping on the effort - the product looks polished, slack integration is nice and I am a believer that there's a lot of room for improvement in this space. Had I been looking to "begin keeping a team notebook", I'd sign up and give it a shot based on what I've read from the site, but I'm not that guy, unfortunately. Best of luck, either way!

[0] I feel dread the moment I find the need to use "AllInText: " in my search query.

[1] And I'll be the first to admit that I'm really particular, and I'm probably not a good target to build a product against.

[2] No, I didn't want to bold the whole line, just the word. I didn't want to indent that whole paragraph, just the first line. Why is that one miserable bullet indented 1.5 times further than the rest and when I hit the "unindent" button, it becomes 0.5 times as indented as the rest. That should be a "Heading 1". No, just that. Not the rest of it. And why did you move everything down another line there, but not anywhere else? (/rant)

[3] I have several .css files for formatting Markdown in a variety of ways -- even being able to use it to print up a proper "proposal"-style document complete with a cover-page. My company has a gorgeous Word template for all of that. My Markdown .css creates output that's indistinguishable from that template. I hate Word this much.

[4] So now the target audience for my magically wanted product is ... a few people on Hacker News who take notes like me. See [1] (:

But the complexity of their structure makes it really hard for non technical people to apprehend. Channels make Slite easy to use for anyone in your team. The second thing is that Notion is built like google docs or paper with a loose notion of team : it's an open tool, where permissions can get messy pretty fast.

We have teams of 150+ people on Slite for this reason.

We clearly have a lot in common with Quip. The main difference as of now is organization : Quip is organized exactly like a google Drive, with nested folders while Slite uses channels. It makes the content accessible, permissions easy to manage and actually shows your team important changes of the content.

The other thing really different that we're building is integrations: Quip focuses on in-editor integrations (which are great, we're working on those as well). But for the rest, unlike quip we keep a simple markdown-compliant (& thus universal) format, which let us fetch and push content to all your toolchain.

I still think having all the information compartmentalized is a waste of time. The integrations that we are developing aim at solving this : Slite will integrate with your github documentation and your Greenhouse pipe so that the members that need the information but don't use the tool everyday (typical in an hiring process) can see the information while those whom it's the job will keep using it as usual.

The fact of having collaborative editing, an organization that actually works for teams & content shared by default among others makes all the difference.

I love as a product person Workflowy or the concept of gingkoapp (and notion quoted above also relate to that I think).

The problem of complex structure is having a part of the team writing knowledge with comfort, all the rest not able to retrieving it, it really defeats the whole purpose.

That's why we're really focused on making information easy to write and easy to access without complexity for the rest of your team. And the most straightforward feature to allow structured data to us is simple internal links, like in a wiki. You can just type @+ name of your note to create an link internal to your Slite.

To be noted: our public API will be available soon and will let you develop sync mechanisms with other tools if needed.

The thing is we solve way more issues for teams between 20-200 people, as they are the one struggling with process and knowledge sharing. The strategy we have to convince them is by integrating in their workflow : if Slite can solve their issues while requiring a low-cost setup by integrating in their toolchain, we think it can prove value quickly enough for those teams to adopt it. And clearly Skype or Office will be at some point included in those integrations.

As for the Exchange servers to be honest I have no idea and it will highly depend on our users' demand.

For the differenciation with Slack, the similarity really stops with the channels pattern. Using Slite allows you to separate use cases: Slack or equivalent to communicate instantly, Slite to write and retrieve information.

As a back story, Slack did try something similar a few years back: they built Slack posts with a similar vision in mind. But having those burried in threads and writing in a constantly ringing place defeated their purpose. From talking to our users, it seems like really few people use posts as they were intended in the first place. At the end of the day, having to organize your content and handling collaborative edition is a job for a standalone product

For the wording indeed, a teammate just mentionned the same thing on "public" wording, we'll think of a better term, "team-wide" maybe.

As for the templating option it's clearly something we're thinking about, the challenge is to make the feature simple enough.

The reason behind that is Slite's UX and the fact we have designed the tool since day 1 to hold not only "wikis" but also meeting notes, specs, interview, snippets and so on.