Beyond "note-taking app": a positioning framework for three audience profiles #9572
Replies: 3 comments
-
Beta Was this translation helpful? Give feedback.
-
|
A third option: I've started a simple solution for local sync. Conceptual prototype, not intended for production use. |
Beta Was this translation helpful? Give feedback.
-
|
@eliandoran Following the discussion about having something like PikaPods: I think the simplest viable stack is Coolify + Caddy + one Docker Compose resource per user - wildcard DNS, automatic SSL, isolated volumes, resource limits, and a REST API for eventual automation. For context: I run TriliumNext on a homelab, push data out via Tailscale, and keep a backup instance on a $3 Interserver VPS. I was close to signing up for PikaPods. I can wait for a community solution instead. Oh ... side note: the Python script for Markdown backups is running well, and sync works via Syncthing across desktops, laptops, and Android, with an encrypted backup(untrusted checked) at the VPS too. |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This builds on a discussion started in #9084 (Luhmann's Zettelkasten and Trilium Notes), where the question of Trilium's intended purpose first came up.
Note: I'm sharing this as a user observation, not a roadmap, or a "right and wrong" decision. Take it as raw material, or just a brainstorming spark for whatever direction the project wants to go.
Building on my previous points about positioning and the three-profile framework, I want to go a layer deeper on the vocabulary problem — because I think the words we use to describe Trilium are actively costing it users from each of those three profiles.
The label "note-taking app" is the first conversion killer
A researcher looking for a Zettelkasten environment, a developer looking for a programmable personal database, or even a general user looking for a "second brain" will not self-identify with "note-taking." They'll walk past Trilium without stopping.
The homepage, the GitHub description, and the README all need different vocabulary depending on who's reading. Here's what I'd suggest per profile:
Profile 1 - The Average User
This audience doesn't respond to acronyms or architecture diagrams.
They respond to outcomes and metaphors.
Terms that land:
The friction-reduction sync proposal I mentioned earlier (the 1-click PikaPods plugin) is inseparable from this. The vocabulary can open the door, but if setup requires reading three wiki pages, this audience leaves. Both need to happen together.
Profile 2 - The Researcher
This is arguably Trilium's most underserved audience and one of its strongest fits. Researchers need typed relationships between concepts — not folders. Trilium's attribute and relation system is exactly that, but the current messaging doesn't surface it.
Terms that land:
The key message for this audience: Trilium models relationships between ideas, not just a hierarchy of documents.
Profile 3 - The Developer
Developers respond to technical precision, and the current description undersells Trilium badly. Three framings that would make a developer stop and look twice:
platform), Trilium lets you write frontend and backend JavaScript natively, inside the tool, to automate your own workflows. No one else does this.
Calling it a "note app" for this audience is like calling PostgreSQL "a place to store text."
A one-liner for the GitHub description:
Summary
The core is already there, and as I noted before, it's stronger than anything else in open source combining total data ownership, a real graph model, and deep programmability. The gap is just in how it's introduced.
These are just patterns I noticed from the outside. The maintainers know the community far better than I do.
Beta Was this translation helpful? Give feedback.
All reactions