We'd tried different apps, and most of them seemed to lean toward one of two extremes. Some had really pleasant, simple interfaces, but sooner or later we'd run into missing features, especially around AI and working with our notes in different ways. Others offered an impressive amount of functionality, but their interfaces sometimes felt like the control panel of a spaceship. You'd open the app to write something down and end up navigating through several layers of UI.
We wanted to see if we could find a reasonable balance between those two approaches.
That's how FixNote started. Our idea was to bring together the features we'd actually want from a notes app in 2026 while keeping the everyday experience straightforward. We spent quite a bit of time experimenting with the interface, trying different approaches, and figuring out where additional functionality genuinely helps and where it just makes things harder.
As development progressed, we found ourselves spending more and more time thinking about privacy. We wanted to be able to sync notes across devices, collaborate with other people, and use AI without giving our server access to the contents of everyone's notes.
We liked how Anytype approaches local encryption and recovery phrases, and it partly inspired our own implementation. In FixNote, your notes are encrypted on your device before they're synced. When you create an account, you get a 12-word recovery phrase used to protect access to your encryption keys. Our server stores the encrypted data, while the keys needed to read it remain under your control. You can also use the app entirely offline without creating an account.
That decision influenced quite a few things we built afterward.
For example, we wanted searching through notes to feel natural, so we integrated a local model for semantic search. We also added offline voice transcription, since sometimes it's easier to record a thought than type it out. Both can work directly on your device.
Then we started experimenting with connecting FixNote to AI assistants.
We implemented a local MCP server so tools like Claude, Cursor, and Codex can work with your notes through permissions you control. You can decide which folders are accessible and whether an external tool is allowed to make changes.
We're now testing a remote MCP relay as well. The idea is fairly simple: when you make a request through something like ChatGPT or Claude, the relay forwards it to one of your active FixNote clients where you've explicitly enabled access. The client handles the request locally and returns the result.
This means we don't need to keep a decrypted copy of your notes on our server to support these integrations. Of course, if you're using a cloud AI model, the content you choose to make available through MCP can still be sent to that provider. For people who prefer to keep AI processing local, we also added support for Ollama.
Collaboration brought its own challenges. We wanted people to be able to share and edit notes together while keeping the content encrypted. Each shared note has its own encryption key, which is encrypted separately for every participant and stored in their personal vault. The server manages permissions and synchronization, while the actual note content remains encrypted from it.
We've recently reached a point where we're happy with what we've learned from the initial usability phase. We've tested our main ideas, worked through a lot of the technical challenges, and now have a working version available for Windows, macOS, and the web.
Our designer is currently turning those experiments into the production UI/UX, and we're developing the mobile version in parallel. There's still quite a bit we'd like to improve, but we figured this was a good time to start sharing what we're building and hear what other people think.
If you're curious, you can try FixNote here:
I'd especially love to hear from people who use note-taking apps regularly. What keeps you using your current app, even when something about it frustrates you?
We're still figuring out where that balance should be, so feedback would be genuinely useful.
Top comments (3)
The distinction between local processing and disclosure to a cloud model is helpful. For the relay, I'd test revocation while a client is offline: enable a folder, disconnect that client, revoke access from another device, then reconnect it with an old request still queued. Does it check current permission before reading the note and again before returning the result? A visible "waiting for an authorized client" state would be useful too. I'd want an unavailable client to fail clearly rather than quietly route the request through a different device with older permissions.
Thanks, great points! Revoking access while a device is offline and the fallback to another device are exactly the kind of edge cases we want to get right, so we’ll dig into them. The "waiting for an authorized client" state is a nice idea too. Appreciate it ❤️
Some comments may only be visible to logged-in visitors. Sign in to view all comments.