How 30 comments rewrote my software license before launch
Last week I posted why LockMargin - my local Financial OS for
freelancers - is $49 once instead of a subscription. I had zero
customers. I said that upfront.
I expected opinions about pricing. Instead I got a design review.
The comments followed me through the weekend and kept coming after.
I wrote the full reasoning up separately - link at the end. Here is
what changed in the build.
- From "licensed" to "owned."
One commenter, AleksandraZhd, found a hole I hadn't closed: if v1 is
sold as a one-time purchase, "licensed" isn't specific enough to say
what the customer actually owns.
So the license now records the purchased version. Buy v1, you own
v1.x - patches and platform fixes included. The 50% major-upgrade
discount is a separate benefit, not part of the original entitlement.
That distinction is the difference between owning a version and
renting a promise.
- The v1/v2 line, drawn before money exists.
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 customer reasonably say "I paid for that?" If yes,
it ships as a v1.x update.
Keeping v1 working on next year's Windows is v1.x. A whole new module
is v2. Platform compatibility stays v1.x forever - otherwise "you own
it" quietly becomes "you own it until Windows changes something."
I'm putting the rule in the license now, because once v2 is being
sold, every ambiguous decision has an obvious financial incentive
behind it.
- No phone-home. Two parts: technical and business.
The technical part. If activating on a new machine requires my server
to answer, then "one-time purchase" eventually depends on my business
still existing. 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.
The business part. The license says one person, your machines - a
desktop and a laptop, not a key passed around. I can't enforce that
offline, and I won't build a server to try. A leaked $49 license
identifies one purchase, not the product. That is a business cost I'm
willing to accept. And if $49 is too much today, you don't need a
leaked key: the Start tier is free to try - up to 5 clients, 5
projects a month, no account, no card.
What didn't change: no subscription, no "12 months of updates" middle
ground, no bundles. The product is something you buy, not something
you keep renting.
The thread gave me something better than marketing advice: an
architecture review I didn't pay for.
Not every comment survived the filter. AleksandraZhd's hole changed
the license. XGenHacker's A/B test - show a subscription to some
visitors, one-time to others - got archived. At my traffic it's a
coin flip calling itself data, and a subscription on the page, even
as a test, breaks the promise. I acted on three comments and archived
a handful. I'm still not completely sure my filter is right.
The raw thread is on my profile - unedited. The mistakes are still
there. The full reasoning, including the parts I'm still unsure
about, is on the blog:
lockmargin.com/blog/how-public-feedback-rewrote-my-license.html?utm_source=indiehackers&utm_medium=social
For people who've done this before: how do you know which feedback is
a signal and which is noise?
I think the strongest part of this process is that you separated “can I technically enforce this?” from “is this business risk worth enforcing?”
I’d apply the same discipline to the pricing model before launch.
Right now, “one-time purchase, no subscription” is still partly a product philosophy decision. I’d turn it into an economic test.
For the first real customers, track:
license type chosen → activation → number of active client/projects → support/update cost → repeat use after 30/60/90 days → request for new features/updates.
That will tell you whether a one-time license actually behaves like a one-time product, or whether customers expect an ongoing service relationship that creates recurring cost without recurring revenue.
I also wouldn’t treat leaked keys as the main risk unless they materially affect paid conversion. If a leaked $49 key only represents one lost purchase and enforcement would require a server you don’t otherwise need, accepting some leakage may be the rational choice.
The two numbers I’d want before revisiting subscriptions or a middle tier: what ongoing support/update cost do you expect per active customer, and what percentage of users are likely to keep using the product beyond 6-12 months?
You applied the same discipline to pricing, and that scrutiny is warranted.
One constraint reshapes the test, though: the app has no telemetry, by design. The funnel you outlined—activation, active clients, repeat use—is mostly unmeasurable here. I can't watch customers use the product. I chose that trade-off, and I accept what it costs the analysis.
So the test runs on the data I do have: sales, upgrade purchases, support emails. The payment processor and my inbox are the only sources of truth. The proxy I'll watch instead is Start-to-Standard conversion within the first 30 days.
Your two numbers, as honest estimates:
Support cost per active customer in year one: a few emails, about 15 minutes each—bounded, because the license caps my obligation at the version sold.
Retention beyond 12 months: I don't know. My structural guess is high, since the data lives on their machine and the tool keeps working, but a guess is what that is. The v2 upgrade rate is my only real proxy for that.
The risk you named is the real one: a service relationship expected at a one-time price. The license is written to bound it—v1.x means patches and platform fixes, not new features.
Where do your two numbers come from—a one-time product you've run, or a subscription one?
Signal vs noise is a measurement boundary problem. AleksandraZhd's hole about 'owned' vs 'licensed' was signal because she identified an actual ambiguity that changes customer behavior - it separates 'I own this version' from 'I rent a platform.' XGenHacker's A/B test was noise because at your traffic it can't produce actionable data. Your filter separates feedback that constrains future decisions from feedback that just adds options. You acted on comments that made your own choices harder to avoid later - that's how you identify signal. Noise feels productive in the moment (more features, more options) but creates future regret. Signal feels restrictive ('you can't do X') but creates future clarity.
That is a sharper description of my own filter than I could have written. I acted on the comments that made future decisions harder to reverse - but I hadn't named why that felt right. Your "measurement boundary problem" framing is the honest mechanism, stated plainly.
One boundary condition from the other side, though. A constraint can also be noise if it protects the wrong promise. Hardware binding was on my first shortlist two weekends ago, when I started the license research. It didn't survive one pass through my own constraints, because it protects my revenue from the honest buyer instead of protecting the buyer from me. So the test I'm adopting is yours plus one clause: the constraint has to protect the promise to the customer, not the seller.
I'm writing that into my decision log as the filter: does this feedback constrain a future decision in a way that protects the buyer's side of the promise?
Where did the boundary come from for you - a product decision you watched go wrong, or somewhere else entirely?