Why we built a notes app
on a code editor.

Every notes app makes a foundational decision before it makes any other, even if nobody writes it down: what do you build on? The common answer is a slim Electron shell around a web editor. We took a stranger route. NoteX Desktop is a fork of Code - OSS, the open-source project behind Visual Studio Code, with the IDE stripped away and a Notion-style note editor put in its place. This post is the honest engineering version of why: what the fork gave us for free, what it forced us to rebuild, and what it costs to this day.

The decision

The obvious plan was the slim one: bundle our web editor in Electron, add a sidebar, ship a 40 MB installer. We already had the editor; NoteX Web runs it in the browser today. But a desktop app carries different expectations than a tab. It has to open instantly, every time, for years. It has to handle thousands of local files without a server in the loop. It has to work offline as a permanent condition, not a degraded mode. And if it wants to be a platform rather than a viewer, it needs an extension system that will not take the whole app down when one add-on misbehaves.

Each of those is a multi-year engineering problem, and each of them is already solved, in public, in the most battle-tested desktop text platform ever shipped. Code - OSS starts fast because a decade of profiling work went into making it start fast. Its extension host is the mechanism that made VS Code the most popular editor in the world. Its update pipeline quietly ships new builds to tens of millions of machines. We could spend our first two years rebuilding a worse version of that plumbing, or we could fork it and spend those years on notes. We forked it.

What you inherit on day one

The inheritance is bigger than it looks from outside, because most of it is invisible when it works:

• Startup speed. The engine cold-starts in under a second on a typical laptop in our internal benchmarks. We did not build that; we inherited it, and our job is not to ruin it. More on this on the speed page.
• The extension host. Extensions run in a separate process with a real API boundary, so a crashing add-on cannot freeze your notes. NoteX points this machinery at Open VSX, the open marketplace, behind a curated, deny-by-default allow-list. That is how Claude Code, Codex, and Continue arrive as native add-ons instead of integrations we hand-build.
• Webviews. The platform has a mature system for hosting rich custom editors inside the workbench, with the sandboxing and lifecycle work already done. Our block editor lives there.
• The command palette. Keyboard-first navigation, fuzzy matching, rebindable shortcuts, and the Ctrl+/ shortcut map came with the house.
• Update infrastructure. The same background update protocol VS Code uses, pointed at Lisan's own update servers. Users keep writing; updates install themselves.
• Themes. A theming engine deep enough that we ship 8 built-in themes and still stay compatible with VS Code themes people already love.
• Window management. Tabs, split views, drag-to-rearrange, session restore. Real multi-document ergonomics, not one page at a time.

What you have to rebuild

The fork buys you the theater; it does not buy you the play. Four things had to be built or replaced outright.

The editor surface itself. The engine's native editor is built for code: monospace text, line numbers, syntax tokens. Notes need blocks. We built a TipTap-based editor and registered it as the default surface for note files: headings, nested to-dos, resizable tables, callouts, toggles, multi-column layouts, Mermaid diagrams, LaTeX math, the whole block editor. This was the single largest piece of work in the app, and no fork shortcut exists for it.

The explorer. A file tree is not a notes tree. Notes want per-note icons, favorites, a private section beside the shared workspace, drag-drop nesting, and a trash you can restore from. We replaced the file explorer as the primary sidebar and kept the original available as an optional developer view, off by default.

De-IDE-ing the chrome. This took longer than we expected. Menus full of developer verbs, panels for debugging and terminals, a status bar reporting encodings and line endings: every piece had to be hidden, rerouted, or given a notes-shaped replacement, without leaving dead ends behind. The goal was an app where a writer never suspects the ancestry, described in full on the desktop app page.

The file format. Code editors edit text files and store nothing else. A note carries metadata: its icon, its cover, its timestamps. We designed .notex as open JSON with the metadata inside the file itself, so a note stays whole when it leaves the app, alongside native editing of plain Markdown. Why the format looks the way it does is a post of its own.

The honest tradeoffs

First, size. The installer is about 140 MB. A minimal Electron notepad can be a tenth of that, and if a tiny footprint is your top requirement, we are not going to argue you out of it. Our position is that the megabytes are the engine, and the engine is why the app is fast, extensible, and updatable. But it is a real number and we would rather print it than have you discover it.

Second, upstream. Forking a project that ships a release nearly every month is a subscription, not a purchase. We continuously merge upstream changes, which means keeping our modifications layered and disciplined so the merges stay tractable, and it means occasionally redoing work when upstream refactors underneath us. We pay that cost on purpose: every merge brings performance, security, and platform fixes from one of the most active codebases in open source, fixes we would otherwise have to write ourselves.

Third, surface area. A platform this large has settings, behaviors, and edge cases we did not author and are still finding. Hiding complexity is not the same as deleting it, and once in a while a seam shows. We treat every such report as a bug in the de-IDE-ing, not as the user holding it wrong.

And the boundary worth stating plainly: the fork is the desktop story. It is Windows today, macOS in the works, and it is a different codebase from NoteX Web, which shares the block editor philosophy and the sync layer but lives in the browser.

Would we do it again?

Yes, and the reasons compounded after launch in ways we did not fully predict. When AI coding agents became the most interesting software of the decade, they shipped as VS Code-compatible extensions, which means they run inside NoteX natively, reading and editing notes as files. We did not build an AI integration; the foundation made agents a catalog entry. The same is true of the PDF toolbox and of themes: the platform keeps absorbing features that would each have been a project on a slimmer base.

The test we set ourselves at the start still holds: a writer who never opens the developer views should experience a calm, instant, Notion-style notes app, and never once think about compilers. If that is what you find when you try it, the fork did its job.