Show HN: SaaS for making software documentation less annoying

For user-facing documentation, I noticed Docusaurus (https://docusaurus.io/) coming up in conversations more and more, so finally bit the bullet and moved our customer-facing documentation to use docusaurus as well (originally using a modified mkdocs).

Gotta say, Docusaurus has worked out great for us. Smooth migration if you have markdown already, everything just works, and a lot of sane defaulting

I also love docusaurus and their easy of migration and use with markdown is something I've tried to bring to my tool as well.

Glad you are happy with it and if you just migrated you probably don't want to do it again this soon but if any of our other features interest you or you need online wysiwyg editor as well, definitely keep us in mind.

I don’t think the landing page sells it well enough. There are lots of ways to create docs, and this makes high level promises but I don’t see the magic thing that compels me to try it out.

Also I don’t see how it makes writing documentation easier? It just provides another way of doing it. The AI aspect sounds like it helps once you have the documentation to ask questions. That is a cool feature but not connected to the main pain point you are selling on.

"An AI assistant that lets you talk with your documentation."

This is a nice opening for me to say something in a positive way instead of a negative way: I'm more interested in this sort of thing than some of the other uses of the LLMs.

Consider the use case I've seen bandied about of "This will automatically take your commit and write commit messages!" This is useless to me... but not because of the "but it will lack insight" sorts of reasons. That may be true, but that only makes it less useful, it doesn't remove the use. The reason why I call this useless is, I have no need for the output to live in a commit message. I can take any commit I like, even a commit that already has a commit message, and feed it into a summarizer. In fact if I do it three or four years from now, it'll probably be even better, on the same input.

Taking fixed inputs, just throwing an LLM at it, and recording the output somewhere, is not a useful use to me, because there's no compelling reason for me to do that today when I could even more easily do it on demand, later.

Now, ingesting my documentation (or perhaps even my raw source code) and answering the question I have right now is valuable to me, right now. Maybe in three years the system will be even better, but I have a question right now.

In general, I'd suggest that any startup looking at adapting LLMs look carefully at any place their system involves storing the output of the LLMs somewhere persistent. Marketing fluff, well, I may have personal distaste for that use, but it's a case where it clearly makes sense. Autogenerated documentation for filling in a Wiki suffers from the same problem I'm outlining here.

> I absolutely despise writing documentation

You really should learn that skill because it's very important in most software companies, and mandatory for some fields like the healthcare industry. It is, like unit-tests or code coverage, a skill that makes a difference between a developer and a senior developer.

Also my pain point is when documentation is not written when it's so easy to use nowadays with files in a docs/ directory, wikis, or comments like Doxygen. We don't need more tools, we need discipline. I'm still trying to understand what your service could bring me, and why I would pay for this.

Last but not least, in the comparison page (https://documentationlab.com/blog/best-software-documentatio...), you describe Read the docs as a tool when it's only a web site to store user-generated content (from Sphinx or any other tool). That's why it's more confusing.

I do write documentation, but what often happens in companies is that you are forced to use Confluence or other such software since the documentation has to be available and editable for all kinds of users in your company. Technical or non-technical. This makes it a hassle for developers to use these tools when they really would like your example of docs directory.

What I'm trying to do is to have the same advantages as tool like confluence but make it as developer friendly as possible. With my tool, you can actually just write the docs into the docs directory if you want and then sync them with our cli tool so you can also edit and view them with your browser from anywhere. When a company needs such tool, they also usually have a problem that the documentation is not up-to-date; my git integration is made to address that.

I think if you don't have these kinds of needs or problems I'm describing. You are able to write your docs to the doc folder and don't value the git integration or AI assistant, this probably ain't the tool for you. I completely understand why it sounds useless to you, but from working in the from software industry for a decade I believe there are enough companies with these kinds of problems I'm addressing.

Also thank you for feedback. Based on the comments I'm getting it seems like my web page isn't communicating the advantages of my tool well enough and I'll definitely need to fix that in the upcoming weeks.

Congrats on the launch! I'm curious how you manage syncing the changes from the WYSIWYG editor back to the repo?

If you have two editors, one editing raw Markdown, and another one comes along with the WYSIWYG editor and makes a change in a new commit, how is that change handled? Is the original formatting preserved, with only the new changes injected into the document?

I ask since I've thought about this a lot for my own company[0], and this is a surprisingly tricky thing to pull off.

You usually end up losing all formatting information once a WYSIWYG editor comes in unless you do something clever, leading to very strange diffs.

[0]: https://www.doctave.com

Two immediate nits (and I mean these from a place of love — I am a sucker for docs tools):

- Your splash page's hero image is indistinguishable at first glance from basic Markdown. More than that, it's the kind of thing I'd expect a tool to _automatically_ generate!

- The idea of colocating documentation with the files its documenting is really interesting, and a core pain point of most internal docs ("what do I need to update when I change this file...?") I think your screenshot here can be much improved.

Great and fair feedback. I think you are right that my screenshots don't show the unique parts of my software very well. The point of the first screenshot was supposed to be that you can either work with the wysiwyg editor or just do everything from cli if you never want to leave your vim. But I guess it doesn't get the point across very well. Do you think that screenshots from the version control integration would be better? For example picture of terminal window doing git commit where the system then lets you know that the page X needs an update.

Again thank you for your feedback, you definitely gave me some thoughts for improvement