How a Public Thread Changed How I Define Ownership
Last week I posted why LockMargin is $49 once instead of a subscription. Zero customers, stated upfront. I expected opinions about pricing. What arrived was a design review. Thirty comments, most of them substantive. A few found real holes in how I planned to license the product.
The comments followed me through the weekend. I spent Saturday and Sunday rewriting not the code but the promise. This is what came out of it: not a license redesign — an ownership model. The difference matters. A license is a file. An ownership model is a chain: price, entitlement, updates, activation, piracy, the free tier, support, and what happens if the company dies. Every link has to honour the same promise, or the promise is a slogan.
"Licensed" is not a promise
Before the thread, my design had a boolean: is licensed. One commenter, AleksandraZhd, asked what exactly a one-time buyer owns. The question looks small. It isn't. A subscription buyer rents the current version. A one-time buyer owns something specific, and "licensed" doesn't say what.
So the license now records the version you bought. Buy v1, you own v1.x — patches and platform fixes included. The 50% discount on the next major version is a separate benefit, not part of the original entitlement. That distinction is the difference between owning a version and renting a promise.
A boundary before revenue
The next hole was the border between v1.x and v2. I didn't want it to become a pricing decision every time I ship. The test from the thread: could a v1 buyer reasonably say "I paid for that?" If yes, it ships as a v1.x update.
Concretely: keeping v1 working on next year's Windows is v1.x. Adding a whole new module is v2. Fixing the PDF renderer is v1.x. Rewriting the app around a different idea of bookkeeping is v2.
One corollary: platform compatibility stays v1.x forever. Otherwise "you own it" quietly becomes "you own it until Windows changes something."
The rule goes into the license now, before v2 exists and before v2 money exists. Don't negotiate the promise after you've collected the money. Once revenue is on the table, every ambiguous decision has an obvious financial incentive behind it.
The quiet killer
Then AleksandraZhd came back with the sharpest note in the thread: "If the licence check ever has to phone home, even once on a new machine, then 'forever' has acquired a dependency on your servers still being there." She was right that it is a build decision, not a policy one.
So the license is a signed token. The app verifies it locally with a public key it already has. Move to another machine, paste the license, it works. No activation server. No revocation server.
And a clarification I owe the reader: a v1 key doesn't die when v2 ships. It simply doesn't grant v2. A new version does not invalidate an old purchase. It creates a new purchase. That sentence is the whole model.
What DRM cannot do
Here is the objection I had to face myself. Without a server, nothing technically stops someone from posting the app and a valid license key on a torrent. True. I checked what the alternative costs: machine binding means an activation server, a key database, monitoring, support tickets. Two days of development, maybe three. And one day the server falls over — and the honest buyer can't activate, while the pirate runs a crack that removes the check. The cost of protecting honest buyers from a relatively low-value threat is paid by honest buyers.
So the boundary is a contract, not a checkpoint: one person, your machines. A desktop and a laptop. Not a key passed around. Each purchase gets its own signed key. The name inside it is the name on the payment record — the one you gave the payment processor, not a nickname; the email stays optional metadata. A deed, not a master key. A leaked key identifies one purchase, not the entire product.
And the honest ceiling: a determined pirate gets in anyway. Determined pirates were never customers. I'm not trying to make piracy impossible. I'm trying to make ownership honest. Don't claim a protection the architecture cannot actually provide.
The demo is not a funnel
The same reasoning produced the free tier. If "try before you own" requires a leaked key, the model is broken. So Start exists: free to try, up to 5 clients, 5 projects a month, unlimited invoices. No account, no card, same encryption, same offline database.
Not a countdown. Not a crippled subscription. Not an account funnel. If you have to buy a product to find out whether you want it, the seller built the wrong kind of friction.
Five clients is not a limit so much as a diagnosis. If you have more, you already know you need the tool. The exact numbers are a guess and may move. The principle won't: the free tier is for trying, Standard is for owning, and your Start data comes with you — because it was always yours. Never use a user's data as an upgrade lever.
The promise survives the company
The weekend added one more question the thread only touched: what happens if LockMargin stops?
If my servers vanish tomorrow, every copy keeps working. If the payment processor vanishes, purchased licenses keep working — they were never checked against it. If development stops, v1 still works. If I disappear, your data stays readable: SQLite, JSON, CSV, formats any tool can open in ten years.
A valid license should never depend on the continued existence of the company that issued it.
The real test of ownership isn't what happens when the company is healthy. It's what happens when it isn't.
The manifesto already contains a contingency: if LockMargin is ever sold and the buyer won't honour the promise, the data layer goes open source. I'm still working out the exact legal shape of that sentence — what exactly opens, under which license, who decides. The direction won't change. The sentence just has to be as honest as the promise.
What else changed
Other commenters left fingerprints.
hamid_founder26 named the frame: this is a model decision, not a price decision. A price changes in an afternoon. A model can't change without breaking the promise that sold it. He asked how I'll measure the upgrade rate without telemetry. No telemetry is needed. Sales records are enough: v1 sales one line item, upgrade purchases another, cohort by cohort. The rate goes in a plain text file next to the database. A spreadsheet would be too ironic for a tool built to replace them. Published either way. If I choose the metric, I don't get to choose the result.
XGenHacker proposed an A/B test — show a subscription to some visitors, one-time to others. I'd love the data. At my traffic it's a coin flip calling itself data, and a subscription on the page, even as a test, breaks the promise. Some experiments cost more than their results.
mjprintz asked what support looks like after ownership. When someone owns a tool, "it still works" is not a feature, it's the baseline. I answer emails myself. Sometimes at 3 AM, sometimes two days late. That is a habit, not a contract — habits age better than promises.
Why trust a public thread over my own judgement? Because I was looking from the inside. The comments weren't smarter than me. They were outside. That is the entire value of building in public: blind spots don't look like blind spots from within.
What I still don't know
- Will $49 produce enough revenue to keep me honest and fed?
- How many Start users become Standard customers?
- How many v1 buyers come back for v2 at 50% off?
- How much support does a one-time customer actually need?
- How much leakage actually happens?
- Does the v1/v2 test hold when real money is involved?
I can design the rules now. I can't know whether the market agrees with them yet. That's fine. The rules get published either way, and so do the numbers.
If you sell software, three questions are worth answering before your v2 exists: what exactly did the customer buy? Where is the line between a patch and a new version? What breaks if your servers disappear tomorrow?
And if you've shipped one-time with paid upgrades, I'd like one data point: what upgrade rate did you actually see? A number beats an opinion. The raw thread is on my Indie Hackers profile — unedited. The mistakes are still there.
Vlad Shiyan writes the code, breaks the features, and answers the emails. Own your tools for $49 once, or read the manifesto first.
Ready to own your freelance data?
Own your tools for $49 once → Read the Manifesto →No subscription · No account required · Your data stays yours forever