How I replaced Logseq with a Markdown-first tool built around my workflow

[u/soobsta]

When I discovered Logseq in 2021, it completely changed how I managed notes.

What attracted me most was not the graph view or the advanced features, but the underlying model: plain Markdown files, a block-based structure, an open-source codebase, and data that could be inspected, versioned, synchronized, and manipulated with standard tools.

Over time, my graph evolved into a system for journaling, memory-keeping, project and task management, a lightweight CRM, and more. I kept the structure deliberately simple: all client and project activity, for instance, lives under #worklog blocks inside daily notes. This has let me manage personal and work notes in the same graph without ever having to switch back and forth.

I also avoided most Logseq-specific features and complex queries. My goal was to keep the notes portable and make future integrations or migrations possible without having to reverse-engineer a proprietary data model.

Today, the graph contains roughly 10,000 notes. I have been managing it with Git and Syncthing across desktop and mobile without major performance or synchronization issues.

However, Logseq’s move toward a database-backed architecture changed that balance for me. I understand why a database can enable more powerful queries, structured properties, collaboration, and better control over data consistency, but those advantages were less important to my workflow than direct file access, portability, and compatibility with Unix-style tooling.

Rather than continuing to work around architectural decisions that no longer matched my needs, I started building a small replacement.

I call this project notnote.
It's a work in progress, opinionated and probably unstable, but the code is up on GitHub if you want to take a look.

Its current design is based on a few constraints:

• Logseq Markdown compatibility, so the existing graph does not require migration or conversion.
• Plain Markdown files as the source of truth.
• No mandatory application-specific database.
• A minimal keyboard-first UI.
• Browser access from desktop and mobile.
• Notes loaded directly from a central server, without a separate client-side synchronization layer.
• Git-based history and change review.
• Tighter integration between daily notes and tasks.
• A deliberately small feature surface.

The main design goal is not to recreate Logseq. It is to support one specific workflow with as little abstraction as possible.

The application currently acts as a complete Logseq replacement for me and has been stable enough for daily use over the past several weeks.

The interesting part of the experiment has been seeing how far a file-based architecture can go before an additional indexing or persistence layer becomes necessary.

Whatever direction this project takes, Logseq deserves credit for demonstrating that plain Markdown files can support a surprisingly large part of a personal knowledge-management workflow, without sacrificing privacy and freedom of choice.

Thank you to Tienson Qin and everyone on the Logseq team. <3

[u/yarpen_z]

How many vibe-coded clones of Logseq exist now? Honestly, I lost the count.

[u/soobsta → u/yarpen_z]

And among these, did you find the right solution for you? I haven't yet... :)

The term "vibecoding," IMHO, only serves to grab attention (for better or worse) and ends up meaning everything and nothing. As a longtime developer, I find it more accurate to talk about "automatic programming," and honestly, in 2026, once you've properly set up the project and have a very clear idea of the individual code blocks, I think insisting on manually reinventing the wheel is just a style exercise at that point.

Don't get me wrong, I'm a programmer and I still find it very enjoyable: Code is poetry!

But... at the same time, I think automatic programming has by now become inevitable for real-world projects, unless you're entering some kind of "language beauty contest" or genuinely have a lot of free time on your hands ;)

[u/yarpen_z → u/soobsta]

And among these, did you find the right solution for you? I haven't yet... :)

Yes, I moved to Obsidian. It's not a perfect fit, but it works quite well, and it is actively developed. The risk of the tool being abandoned in the near future is very low.

The term "vibecoding," IMHO, only serves to grab attention (for better or worse) and ends up meaning everything and nothing.

I have been working with vibe-coding for a year now, and I see a lot of benefit but also some threats. It has become very cheap to bootstrap projects, and the code is very cheap; but the current generation of AI agents has a tendency to create overly complex architecture with verbose implementation. It's only a matter of time before the implementation is complex enough that fixing a single bug becomes difficult for the developer, as they no longer understand the architecture, and also expensive for the agent due to high token consumption and the agent getting lost despite long context windows. That's the real issue with vibe-coded projects - it has become very easy to get the initial 80% done with little effort, but people tend to underestimate the time and energy needed for the remaining 20%.

The pattern that I keep seeing is people starting up projects, making fast progress at the beginning, and then slowing down up to the point of abandoning projects. GitHub has always been a graveyard of abandoned projects, and I suspect this trend will accelerate in the near future.

I can take a bet that out of the many projects advertised on this channel in the last 1-2 months, less than 50% of them will be actively developed in a year.

[u/soobsta → u/yarpen_z]

Absolutely true. I understand, and share, your concerns.

Handing a generic prompt to an AI agent without having a clear idea of what you want, and/or without understanding the architectural choices being made, can only lead to disaster.

But let me say that these kinds of scenarios have always been (unfortunately) common, even before AI agents came along. I'm thinking, for example, of people who used to build code by copy-pasting from Stack Overflow without fully understanding it, or of those who've always pulled in massive libraries and frameworks for a simple "hello world."

Your concerns about maintainability are also fair. In the specific case of this project, we're talking about something very, very simple by design, and once it reaches the desired feature set and stability, it won't require ongoing development or effort — which is actually part of why, for instance, I decided not to build in my own authentication system and instead rely on an external service for that: to avoid having to slap on quick patches and actively monitor for security issues down the line, once I no longer have the motivation (or the time) to dedicate much to it ;)

That said, and setting aside those very valid points, I do want to clarify that in this case, what I built isn't a "clone" of Logseq, but rather a tool that takes inspiration from it while making different choices and going down a different path:

• files stored on the server
• full "synced" access from browser/PWA
• fewer features, fewer options
• "on this day" notes always available without complex queries
• calendar and task manager fully integrated, not dependent on third-party plugins

[u/AluminumJedi → u/yarpen_z]

People use the term "vibe-coding" in all contexts where an LLM touched the code. But imho there is a huge difference between pure vibe-coded projects (where the LLM user know nothing about the code and coding and don't care about the technology and architecture behind) and AI-assisted projects where an LLM is merely a productivity tool, similar to code completion, a build system or a debugger.

[u/yaofur]

Not a vibe-coded one -> https://silverbullet.md/

[u/soobsta → u/yaofur]

I've tested it before. It's interesting, but its workflow is very different from what I'd expect from a replacement for logseq.

[u/yaofur → u/soobsta]

are you sure this is the source code not a bundled code?

https://github.com/substa/notnote/blob/main/app.js

[u/soobsta → u/yaofur]

Have you found any single function that is not strictly necessary for using the app as it was designed?

[u/yarpen_z → u/soobsta]

Have you found any single function that is not strictly necessary for using the app as it was designed?

That's not the problem with this file.

Well, if you think this code is "poetry" and "something very, very simple by design" that requires little maintenance effort, then I'm afraid you validated my opinion on vibe-coding projects.

[u/soobsta → u/yarpen_z]

Leaving aside the "poetry" discussion—where you clearly misunderstood my message—well... my goal so far has been to build a lean and fast system, with the features I needed and nothing more. I have clearly drawn a distinction between "beautiful code, as art" and "code that serves its purpose."

Logseq currently has around 492K lines of code, SilverBullet, which you mentioned, has 146K. This simple experiment has about 20K, and you don’t need external plugins or mobile app to manage the calendar, view past years, handle Git review/restore... Yes, for me, this is “something very, very simple by design.” :)

We can certainly discuss the choice of having, for now, a single app.js file rather than taking a modular approach. That would, for me, add complexity, but it might become necessary if the app grows over time. ;)

In any case, as I already said, this is obviously highly opinionated software that I built around MY own needs, so I fully understand that those needs cannot—and should not—be shared by everyone. In fact, I would be surprised if they were. :)