Most advice on monetizing open source assumes you are selling something. A product, a service tier, a support contract, a hosted version for the people who cannot be bothered to run it themselves. All of it good advice, and none of it applicable, because if what you are building is a local-first single-user tool then there is no server to run and no subscription to justify. Nothing recurs. Nothing scales with usage. There is no ongoing cost to pass along, which is wonderful for the user and inconvenient for anyone hoping to build a business on it.
So I stopped trying to sell Fardel and started asking people to support the person making it.
That is not really a decision about Fardel. It is how nearly everything I build ends up: open source, no telemetry, no account, and no mechanism anywhere in it that produces a bill. Fardel is just the one I happened to be looking at when the question got unavoidable.
Why selling was never the right model
Fardel keeps track of household finances and personal possessions in one place. Elixir and Phoenix on the inside, SQLite underneath, one database file, nothing leaving the machine. There is no cloud backend, no account, no telemetry, and no part of it that costs me money when you use it more.
Which means a subscription would be solving a problem I do not have, purely so the project fits a monetization template designed for problems other people do have. Charging rent for a service I am not providing is not a business model. It is a costume.
Once that was obvious, the question stopped being "how do I price this" and became "why would anyone want this to keep existing." Those are different questions with different answers, and only one of them has a checkout page at the end.
What the Ko-fi page is actually for
The page is not pitching a feature list. Feature lists are for things you buy, and they age badly: every one of them is a promise with a date on it.
It pitches a stance instead. Software that respects your privacy, built in the open, without the usual trade-offs. No telemetry, no lock-in, no dependency on a platform that can change the rules once enough people are stuck. That stance is the thing worth supporting, and unlike a feature list it survives contact with a release schedule.
So the page reads less like a product page and more like a statement of what the work is for. If that lands, the ask is simple: help this keep happening. If it does not land, no amount of bullet points was going to fix it.
Why the ask survived a rename
Fardel used to be Budgeteer. Two things happened at once. The UI broke badly enough that a rewrite made more sense than a repair, which is a sentence every developer has written at least once and believed at least twice. And the scope grew: Budgeteer tracked what a household spends, while Fardel also tracks what it owns, and at that point the old name was describing about half the thing.
So it got a new one. A fardel is an old word for a bundle, and by extension a burden, which for an app about your money and your possessions is either perfect or a little too on the nose.
What did not change was the Ko-fi goal or the tier structure. A rename is the natural moment to reset everything, the ask included, and I deliberately did not. The relationship I am trying to build is not with a particular repository. There is one Ko-fi page and it has my name on it, not a project's, which was not a branding decision so much as an accurate one. It is with the fact that I keep making things, and keep making them the same way, and will still be doing that after this project has been renamed again by some future version of me who has opinions about the current UI.
Changing the ask every time the code changes would quietly admit the ask was about the code. Keeping it steady is the argument. It is not an oversight, though I accept it looks exactly like one.
Where this actually stands
Nobody has supported it. Not one person, not once.
I am not going to write around that, because the whole pitch here is that I do not dress things up, and it would be a strange essay that made an exception for its own scoreboard. The positioning does not depend on results to be coherent: it is a bet on what the project represents, placed before there is any evidence it pays off. Whether it pays off is a genuinely separate question from whether the framing is right, and I would like to keep those two questions apart for as long as intellectual honesty allows, which is probably about another six months.
Ask me again when the tip jar has something in it. Or do not, and I will keep building it anyway, which is either the strongest part of the argument or the reason nobody needs to pay for it.