I shipped a paid Obsidian plugin with no server, no subscription, and offline licensing
I am an engineer by training but not a software engineer, and I have no coding background. Over the past months I have been building small commercial tools entirely with AI assistance. The latest is an Obsidian plugin, and a few of the decisions behind it go against how most paid AI plugins are built, so I wanted to share them here.
The problem I built for: across reading and PKM communities, people sync hundreds of highlights from Readwise, Snipd, or Kindle into their vault and then never open the folder again. The saved passages pile up into a graveyard. I am not a heavy highlighter myself, I found this pain through research rather than my own pile, and I would rather say that plainly than invent an origin story. The plugin reads the whole folder and writes one synthesis note: a summary, key claims, and topics per source, plus the themes that recur across sources.
The decisions I want feedback on:
No server. Most paid AI Obsidian plugins validate a subscription against a backend, often a Cloudflare Worker with cloud validation and monthly billing. I went the opposite way: zero server, zero database, zero recurring cost. Nothing for me to run, nothing to leak on my side.
No subscription. The Pro license is a one-time purchase, verified offline with an Ed25519 signature. The private key lives in my password manager, the public key is embedded in the plugin, and verification is fully offline. No phone-home, works on a plane.
BYOK, and honest about it. It uses the user's own provider key. I am careful not to oversell privacy: BYOK still sends highlight text to whichever model the user picks, so the accurate claim is no server and no data collection on my side, not "your notes never leave your machine".
Free tier as a lifetime cap, not a monthly reset. Three syncs total for the life of the install. A monthly reset lets people wait out the counter forever. A lifetime cap forces a real decision.
The open question I keep circling: a one-time price with no recurring revenue and no server is a calmer business to run, but it caps the upside hard. For those of you selling one-time licenses for small tools, has the lower support burden and zero infrastructure been worth giving up MRR? That is the tradeoff I am least sure about.
It is in the Obsidian community plugin directory now if anyone wants to look:
https://community.obsidian.md/plugins/highlight-inbox-synthesizer
https://ibrh96.gumroad.com/l/vtqocc
This feels like a very natural fit for Obsidian’s audience local-first and offline licensing actually aligns with user expectations more than most SaaS assumptions
The real tradeoff here feels less technical and more about upside ceiling vs simplicity of running a zero infra product long term
curious if you are fully committed to staying one time purchase only, or leaving room for optional paid extensions later?
That is exactly the tradeoff I keep circling, and you framed it better than I did. The technical side is settled, the real question is upside ceiling versus the simplicity of running something with zero infrastructure.
On one-time versus extensions: I am committed to one-time for the core. I would rather a buyer pay once and be done than feel metered. But I am not against optional paid extensions later if they are genuinely separate value, not the same feature behind a second paywall. Something like a distinct add-on a subset of users actually want, priced on its own. The line I do not want to cross is turning a one-time tool into a subscription wearing a costume.
What I have not figured out is whether that add-on model produces enough to matter without a server, or whether it just adds support surface for little return. If you have seen one-time-plus-add-on work without recurring infra, I would like to hear how it went.
I haven't run a one time license business myself, but from a software engineering perspective, one thing I find interesting about your approach is that you r treating simplicity as a feature, not just a cost saving measure,
my intuition is that optional add ons work best when they are solving a different problem rather than extending the core workflow, otherwise users start feeling like the original purchase was incomplete.
for an Obsidian audience specifically, I could imagine people being more accepting of paid extensions if the core promise remains fully intact and self contained
Agreed, and I think you nailed the distinction. An add-on that solves a different problem feels like a bonus, while one that just extends the core makes the original purchase feel rationed. That second one is the trap I want to avoid.
My small numbers actually back your instinct from another angle. The plugins that sold were the ones clearing outside material people feel guilty about, like unread articles and highlights. The ones that just reorganize the user's own notes did not sell at all. So "different problem, not extended workflow" lines up with what I am seeing.
Appreciate you thinking through this with me, this was genuinely useful.
I appreciated the honesty that this came from research rather than pretending every origin story has to be personal. I’m building Omphalis around a related problem: highlights need more than synthesis. They need a return path to the source and an explanation of why the highlight mattered. In your research, did people mostly want one ‘what did I save?’ note, or did they want help re-entering the original sources later?
Good question, and honest answer: my research didn't give me a clean signal either way. Most threads I read were people venting about the pile itself — "I have 500 highlights and no idea what's in them" — rather than describing what they wanted to do with any single highlight afterward. So I built for the "what did I save" question first, since that's what people actually complained about. The return-to-source need you're describing sounds real, just not something I saw articulated as clearly in the threads I read. Curious how you're approaching it with Omphalis — that's a harder problem than synthesis alone.
Agreed, it's harder, and I think the reason is that synthesis lets you throw the source away. Once you've generated "here's what your highlights say," you don't really need the original anymore. Return-to-source is the opposite: you have to keep the whole thing, cleaned and navigable, so a highlight is never an orphaned snippet. It's still sitting in its paragraph with the argument around it intact.
So the approach is source-first instead of highlight-first. The mark never leaves home. When you save a piece, it gets cleaned and structured (the shape of it: where it opens, turns, gets dense), and a highlight is anchored to its exact spot in that. Re-entering later isn't "find the note about this," it's "drop back into the source at the line that mattered, with everything around it still there." The "why" is a short note in your own words at the mark time if you want one. I deliberately don't auto-generate it, because a confidently wrong "why you saved this" is worse than none.
The genuinely hard part, and the thing I'd flag if you go this direction, is anchoring. Keeping a highlight pointing at the right passage is easy until you re-clean or re-extract the source (a different PDF pass, an article that changed, a transcript re-run) and all your offsets move. That has been more engineering than the comprehension itself. Synthesis sidesteps it completely, which is part of why it's the easier bet.
How are you handling it on the Obsidian side? Are you keeping the highlight tied to the source doc, or does it become its own note once it's synthesized? That feels like the real fork.
It stays tied to the source. The synthesis is a generated, regenerable view sitting on top of the originals, not a thing that replaces them — so the originals stay the source of truth and a highlight always has a home. That avoids orphaning, but it deliberately doesn't try to solve return-to-source the way you are; different bet.
Omphalis is clearly the harder problem of the two. Good luck with the anchoring part — that's the real fork like you said. Happy to compare notes down the line if it's useful.
İbrahim, that's the cleanest framing of the fork I've heard. Synthesis lets you throw the source away. Source-first means you can't. Yours ships lighter; mine lives or dies on anchoring. I'd genuinely enjoy comparing notes as both evolve, especially regarding re-extraction drift. I'm at stanly@tryomphalis.com if you ever want to swap war stories.
Appreciate that — and the offer. For now I'll keep these in the open thread, mostly because other people building similar things seem to get something out of watching two different bets play out in public. If either of us hits something interesting on the anchoring/drift side down the line, happy to share the high-level lesson here too.
This comment was deleted 3 months ago