I tried to pirate my own product
I spent last weekend pirating my own app. Hex editor, patched license
check, a leaked-key scenario, the works. I wanted to know exactly how
long it takes to rob me.
Context for new readers: I'm building LockMargin, a local-first
Financial OS for freelancers. $49 one-time. No subscription, no
account, no server phone-home. The license is a signed token the app
verifies offline, forever.
That design has an obvious hole, and I wanted to stare at it until it
stopped being scary.
What worked, what didn't
The patch took me an evening. If someone replaces the license check
with a "yes," the app believes it. I'm not going to pretend otherwise.
The keygen didn't work, and it shouldn't be able to. Keys are Ed25519
signatures. The public key ships in the binary; the private key never
leaves my machine. You can patch a check. You can't forge a signature.
A leaked valid key works on every machine, because verification is
offline. That's the trade I chose on purpose: a license server would
let me revoke leaks, and it would also mean every copy of my app
depends on my servers staying alive. For a tool whose entire promise
is "your business keeps working even if I disappear," that dependency
would be a lie in the architecture.
The honest ceiling
Here's the sentence I keep coming back to: offline verification has a
ceiling. Past a certain level of determination, any offline check can
be removed. Anything that claims to make a determined offline crack
impossible is snake oil — phone-home DRM, hardware locks, obfuscation
arms races — and the people who pay for it are the honest users, in
friction and false positives.
So I ship friction, not fiction: signed tokens, a binary that's
annoying to patch casually, and a price low enough that buying is
easier than stealing for almost everyone who isn't already determined.
The asymmetry I actually rely on
The part that changed my thinking: the binary isn't the asset. The
data is.
A cracked LockMargin is a shell. What a freelancer keeps in it — five
years of invoices, clients, time entries — lives in an open SQLite
format whose spec is public. The value isn't in my code staying
secret. It's in the records staying readable, verifiable, and theirs.
A pirate can copy the shell. They can't copy a business's history,
and they can't offer the one thing I actually sell: the guarantee
that your data outlives the product.
That's the data-vs-binary asymmetry. I can lose the binary and keep
the customer. A SaaS that disappears can leave the customer fighting
to recover their own history.
What this costs me
Zero customers so far. Early Access opens later this month on Windows;
Standard follows in October. If someone pirates the EA build, I'll
know whether the ceiling held or didn't, and I'll write that up too.
I'd rather ship with the ceiling stated plainly than sell a lock I
know is decorative.
Questions for builders who've been here
- Have you ever attacked your own product? What did you find that you
wished you'd known before launch? - For one-time-payment desktop tools: where did you draw the line
between friction and fiction — and did any customer ever notice the
difference? - If your license check disappeared tomorrow, what would actually keep
people paying?
I wrote up the technical details here, including the exact attack
surface and the friction layers:
https://lockmargin.com/blog/the-honest-ceiling.html?utm_source=indiehackers&utm_medium=social
The un-revocable leaked key is the real long-term cost of offline verification. One mitigation: bind the license token to something identifiable at purchase (order id / email hash) so a leaked key floating around forums is at least attributable, and require a re-issued token for major-version upgrades. You keep the "works forever" promise for current owners while shrinking the leak-and-share market. Staring at the hole until it stops being scary is exactly the right discipline — nice writeup.
Thanks — both mitigations are already in the design, which I take as a
sign the hole got stared at long enough.
Attribution: each purchase gets its own Ed25519-signed token, with the buyer's name from the payment record signed into the payload. Change or remove the name and the signature breaks, so a leaked key remains attributable to the original purchaser. The app also shows "Licensed to: name" in Help — visible friction, not just forensics.
Major-version re-issuance is handled by a max_major entitlement. A v1 token verifies offline forever on v1.x but cannot unlock v2. V2 requires a new token, with Standard v1 owners getting it at 50%. The test I use is simple: could a v1 buyer reasonably say, "I paid for that?"
What I did not solve: a leaked key still works forever within its major. Attribution narrows the leak-and-share market; it doesn't close it. At $49, I'm okay with that trade.
Curious whether you've seen attributable keys actually change leaker behavior in the wild, or whether the name becomes noise once a key lands on a forum.
The piracy test is honest, but the stronger commercial question seems to be the data-ownership guarantee. Do you have evidence that freelancers actually value “your records survive even if we disappear” enough to pay, rather than treating the offline model mainly as a technical feature?
No, and I won't dress anecdotes up as evidence. What I have is
directional: the longest conversations I've had with strangers about
LockMargin — including the license thread and this one — keep landing
on exit. "What happens to my records if you disappear?" comes up more
often than any feature question. Small n, and still not evidence.
The real answer is the same one I owe you from thread #1: the cohort
number. Start→Standard conversion at 30 days will tell me whether the
overall promise — including the ownership guarantee — is strong enough
to turn into payment. I'll publish it either way.
Until then I'm building the checkable version of the guarantee: export
on one machine, restore on another, records identical — plus one
question in the first EA email asking which proof people actually
read.
What would count as evidence for you before launch — the restore demo,
the cohort number, or something I haven't thought of?
That’s a useful signal, especially that ownership keeps coming up. If you’re open to it, what’s the best email to reach you on?
support@lockmargin.com — the same address as in the site footer. It reaches me directly.
And if you have a concrete answer to your own question — what would actually convince you before paying? — send that there too. That's exactly the kind of thing I don't want to guess about.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
Replied by email — thanks for sending it over, Aryan. The public version stands: the commercial question stays open until Early Access starts answering it, and the 30-day Start→Standard number gets published either way. I'll post it here when it lands.
With zero customers so far, would you put a time limit on further license protection work until you've seen what paying users actually need? You've already learned where the offline model breaks. I'd be curious whether early buyers care more about that tradeoff or about seeing a working export-and-restore flow that proves their records will survive the app.
Protection work doesn't need a timebox because it's already closed. The
post already defines the protection boundary: what I kept and what I
deliberately refused. The only license work left before Early Access is
the public license spec, and that's trust work, not protection work.
Your second point is where the hours should go, and I agree. Buyers
can't verify my ceiling; they can verify a restore.
Half of that proof already ships in the public data-layer repo:
decrypt-cli reads the same file the app writes, and the tools/ folder
exports a decrypted container to CSV, JSON, or SQLite. The missing half
is restore shown end-to-end: export on one machine, restore on another,
records identical. That's my next proof artifact before EA.
On which proof early buyers care about more: my hypothesis is restore
wins, and I'd rather measure it than argue about it. Two signals: which
document EA reservers open, and one direct question in the first EA
email. If the data disagrees with me, the data wins.
"Protection closed, proof open" is going straight into my notes. If
you've evaluated tools this way before, I'd like the other side of it:
what was the artifact that settled it for you?