Beyond "note-taking app": a positioning framework for three audience profiles #9572
Replies: 3 comments
|
A third option: I've started a simple solution for local sync. Conceptual prototype, not intended for production use. |
|
@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. |

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.
All reactions