Why I'm charging $49 once instead of a subscription for my desktop app
I spent 10+ years building offline Windows software for factories and
retail. Boring, reliable, local software.
Now I'm building my own product: LockMargin, a local-first Financial OS
for freelancers. Time tracking, invoices and expenses in one encrypted
SQLite file on your machine.
The first question every indie founder gets is "what's your MRR plan?"
I don't have one. LockMargin is $49 once. No subscription, no account
required.
Three reasons, in order of honesty:
-
I'm the target user.
I paid $19/month for years to store my own invoices on someone else's
server. Charging rent for the same thing would make me the landlord I
complain about. -
The pricing is part of the product design.
The whole idea is "own your business, don't rent it." Putting that
behind a permanent subscription creates a contradiction I couldn't
ignore. -
It's a hypothesis I want to test.
I suspect a $49 one-time purchase feels easier to justify than another
recurring bill when work is slow. That's a hypothesis, not a proven
insight. I have zero customers so far, so I'm not pretending otherwise.
What I'm giving up, with math:
- No compounding MRR. If I sell 100 copies, that's $4,900. Then $0
until the next 100. - No sunsetting leverage. People will pay for v2 because it's better,
not because they're trapped. - I will know exactly how broke I am every morning. No recurring
revenue to hide behind.
The only upsell: 50% off major versions for existing users.
The upside is simple: the customer pays once and owns that version. I
have to keep earning trust instead of relying on subscription inertia.
Status: Windows Early Access opens September 2026. Zero customers.
Building in public.
For those who've shipped one-time desktop tools:
- Would you choose one-time pricing again if you started today?
- At what revenue level did predictability become a real problem?
- How did you keep shipping updates without "they'll cancel if I don't"
pressure?
Happy to share what I learn the hard way.
https://lockmargin.com/manifesto.html?utm_source=indiehackers&utm_medium=social
Intriguing idea, with the once-and-done pricing. I LOVE that as a user in principle, but honestly it would keep me awake at night as a bootstrapping founder. The part that bugs me the most isn't the flat rate, paid once portion, or even the price break for loyalty. Instead, that "12 months of upgrades" is essentially giving your improvements away for free, and you have no idea if they're going to stick around to pay you back when that 12 months is up.
That may also introduce a scenario where you start playing mindgames with yourself in terms of "what constitutes an upgrade, at which point I may lose users?" I can just hear the argument I'd have with myself: "I need to fix X." "But if I fix X, that's an update. Some of my customers would have to pay for that update to get the fix. Will that 50% off entice them to stay, or are my users just once-and-done users?"
In a way, the only customer you ever actually have is the one that buys it tomorrow. Every past customer could conceivably be done and you'll never know. That would drive me crazy. I also wonder if, at zero users, there's actually zero analytics available. How many people actually prefer the subscription, and haven't signed up yet because of that single-purchase hurdle?
I wonder if you could offer a temporary A/B test on your product website: If people buy the subscription, that's a point in favor of the subscription. If people buy the product once, that's a point in favor of the current model. At the end of some period of time, if you have lots in one category and few in the other, the market has spoken. If, on the other hand, you have neither, then something else is holding customers back. That could be an even more valuable signal: revise the marketing, revise the product, whatever. But at least with that A/B test, you'd have options for customers, and data to work with.
Quick correction: I think you're pricing a variant I didn't pick.
There is no "12 months of upgrades" here. You buy v1, you own v1
forever - patches and platform fixes included. A major version is a
new purchase at 50% off, not a renewal. The scope of "free
improvements" is narrower than it sounds: only patches and platform
fixes for the version you own. Everything else is a new version.
On the A/B test: I get the appeal, and I'd love the data. But A/B
tests need statistical power. With the traffic I have right now, I'd
be flipping a coin and calling it data. Worse, a subscription on the
page - even as a test - would break the one promise this whole
project is built on.
So the real test is where money actually changes hands: at launch.
The upgrade rate and the first hundred sales are the market speaking.
I'll publish the numbers either way.
You've clearly thought about early-stage signals. What would you
actually trust when traffic is effectively zero?
Update for those who followed the thread: I wrote up the full reasoning - what changed, what didn't, and what I still don't know - as a long-form piece:
lockmargin.com/blog/how-public-feedback-rewrote-my-license.html?utm_source=indiehackers&utm_medium=social
The short version: the license now records the version you bought; the v1/v2 rule is written down before v2 exists; activation never phones home. The upgrade-rate number still gets published either way.
Shipped and stayed local: Sublime Text ran on offline licence keys for years, and half the classic shareware catalogue did the same. Where I've watched the server sneak back in is never the licence check, it's the trial and the updater: a timed trial wants a clock it can trust, and auto-update wants a channel, and both arrive carrying infrastructure. You've priced the leak risk correctly at $49, so the scheme holds. If you ever add a trial, decide then whether the trial phones home, and keep that decision separate from the licence, which can stay a signed file forever.
The shareware shelf is the longest-running evidence that an offline
key can sustain a business, so I'll take the Sublime precedent as a
weather report, not a hope.
I've written down the two doors you named - trial and updater - as
separate decisions from the license. On the trial side, LockMargin
deliberately has no countdown. The free tier is limit-based: 5
clients, 5 projects a month. A timed trial wants a clock it can
trust; a client cap only wants a counter in the local database. No
clock, no channel, no infrastructure.
On the updater side, the current answer is no channel at all: a new
version is a manual download, the same way you'd fetch any file you
own. If an update checker ever appears, it will be opt-in, and the
license check will never ride along with it.
The license stays a signed file. That sentence goes into the build
spec verbatim.
Of the two doors, which have you seen open first in practice - the
trial clock or the update channel?
The trial door opens first, but the updater opens quietly. A trial gets added the day revenue pressure beats philosophy, and that's a loud decision someone can veto. The update checker arrives as a convenience patch, on by default, and nobody calls it infrastructure until it phones home on every launch. Your cap-based free tier welds the trial door shut: a counter needs no clock, so there's nothing to creep. That leaves one pre-commitment worth writing down now: the day a security fix demands a "please update" prompt, it ships as a signed manual download plus an opt-in checker, decided in the spec while nobody's bleeding. Honest footnote: my seat is web-side attribution, so I watch these doors from outside rather than owning one.
The quiet part is the part I would have missed. A trial is a loud decision - someone can veto it. An update checker arrives as a convenience patch, on by default. By the time anyone names it infrastructure, it has been phoning home for a year.
So the pre-commitment goes into the build spec this week, in your wording where it is sharper: the day a security fix demands a "please update" prompt, it ships as a signed manual download plus an opt-in checker - decided while nobody's bleeding. I would rather write that sentence calm than negotiate it during an incident.
The footnote matters for the same reason. The person owning the door sees the convenience; the person outside sees the hinge. That is one reason the thread stays public.
One question back, from your side of the hinge: in web-side attribution, what was the convenience that quietly became infrastructure - the one nobody vetoed because nobody noticed it arrive?
The tracking cookie itself. It arrived as a convenience, remember this visitor, and nobody vetoed it because nothing shipped: browsers just had it, every tool assumed it, and attribution quietly became something you get from the browser instead of something you build. Thirty years later there's a consent-banner industry whose whole job is negotiating that one unvetoed default, and "90-day attribution window" sits on pricing pages as if the mechanism underneath could promise it. We build server-side partly because unwinding a convenience turned out harder than never adopting it: the default owns you the day the second tool assumes it's there.
The cookie is the cleanest example of the pattern we've been circling - a convenience that became infrastructure before anyone held a meeting about it. Thirty years of consent banners as the price of one unvetoed default. Your line about the second tool assuming the default goes in my notes next to the license rule, because it's the same mechanism seen from your side of the hinge.
Turns out we're refusing the same thing from different sides: you won't let the cookie back in, I won't let a license server in. Good company to be stubborn with.
The ‘model decision, not a price decision’ framing is useful. Once the first buyers purchase on the promise of ownership, switching later is painful. The JetBrains-style ‘12 months of updates then you keep the last version’ middle ground is interesting because it keeps some recurring revenue without trapping people. For a solo founder the pure one-time model also forces very honest accounting — every morning you know exactly where you stand. I’m curious how you plan to track the upgrade rate cleanly once you have real numbers. That feels like the only metric that will actually tell you if the hypothesis is working.
No MRR means no curve to hide behind. Every month starts at zero and
tells you the truth. I've decided to treat that as a feature.
The JetBrains middle ground keeps some recurring revenue, but it also
keeps a recurring promise. I chose the simpler shape: one purchase,
one version, no recurring obligation on either side.
On tracking the upgrade rate: the app has no telemetry, so the payment
processor is the only source of truth. That is enough. v1 sales will be
one line item, the 50% upgrade purchase another. The rate is the second
divided by the first, cohort by cohort. No dashboards, no funnels.
Keeping the numbers in a spreadsheet would be ironic for a tool built
to replace them, so it will be a plain text file next to the database.
The hard part is not tracking the number. It's publishing it when it's
ugly. That commitment stands: the number gets published either way.
Have you shipped with a one-time model yourself?
No, I haven’t. I’m building a subscription product myself, so the pure one-time path is something I’m watching from the outside.
The part that lands hardest is the “every month starts at zero” framing. There’s something clean about removing the soft cushion of recurring numbers. It forces the honesty you described.
I like the decision to keep the upgrade rate in a plain text file. For a tool that is itself about ownership and simplicity, that consistency feels right. Most of us would reach for a spreadsheet or a dashboard out of habit.
Looking forward to seeing the number when it exists, ugly or not. That public commitment is rarer than it should be.
Then we're the two sides of the same experiment. You get the curve; I
get the truth at zero.
The number goes up when it exists. Ugly or not. And I'd like the
comparison a year from now: your churn against my upgrade rate. Two
honest numbers, side by side.
If your subscription ever starts feeling like rent - you know where
to find me.
Ha, fair. Two different experiments running in parallel.
I’ll take the curve for now and see what the real churn number looks like once I actually have customers. Looking forward to that side-by-side comparison whenever both numbers exist.
Deal on the open invitation too.
Deal. When both numbers exist, they go up side by side - mine here,
yours wherever you keep yours. No spin on either side.
And the invitation has no expiration. If the curve ever starts
feeling like rent, the door is where it was.
Good luck with the subscription. Mean it.
The part I find most convincing here isn't the $49 itself, it's that the pricing matches the product's promise — selling "own your business, don't rent it" on a subscription would undercut the whole local-first, encrypted-SQLite pitch. The risk I'd watch is that one-time desktop pricing tends to live or die on distribution: with no MRR, every month starts at zero, so your launch channel becomes the real product decision. One concrete suggestion before Early Access in September: consider a paid "v1 + first major upgrade" bundle at a slightly higher price, so early buyers pre-fund v2 without you inventing a subscription. I'd also make the 50% upgrade discount visible on the sales page from day one — it quietly answers the "will this be abandoned?" objection that kills a lot of one-time purchases. Genuine question: for freelancers who already use spreadsheets plus a bank export, what's the single moment where LockMargin saves them enough time that $49 feels obvious?
Distribution is the one I lose sleep over. With no MRR, the launch
channel isn't marketing - it's the product decision. So I'm building
in public, one thread at a time.
On the bundle: I considered it. I'm keeping the promise simpler - the
50% major-upgrade line is on the pricing page today, exactly because
it answers "will this be abandoned?" without inventing a subscription.
Your genuine question deserves a genuine answer. The single moment is
usually an unpleasant one: an invoice sits 40 days unpaid, and the
spreadsheet never once flagged it. Finding out why takes an hour of
archaeology - digging through tabs, cross-referencing dates, hoping
nothing's broken. The same answer takes five seconds when the records
are already there - and you can show the client the same view, no
explanation needed.
At that point, $49 stops being a price and starts being obvious.
Does that match what you've seen freelancers deal with, or is the real
pain somewhere else?
Your pricing strategy reminds me of what Affinity did before Canva bought them. The one time fee that included free minor and patch versions is what got me and a lot of others to ditch Adobe. They also gave a discount to existing users who wanted to upgrade to the next major version.
I think that one-time charge and getting their software closer in parity to Adobe's counterparts were key in getting growing their user base and eventually getting acquired.
The Affinity comparison is the sharpest one in this thread - and the
most useful, because it splits the story in two. Pricing got you in
the door; the tool kept you there. You didn't stay because of the
fee. You stayed because it did the job.
That's the honest risk on my side. The $49 gets the conversation
started. The product has to finish it.
On the acquisition part: Affinity's story changed when Canva bought
them - exactly the scenario my constitution is written for. If
LockMargin is ever sold and the buyer won't honor the promise, the
data layer goes open source. I wrote it before it was needed.
What finally made you switch from Adobe - the price, or the moment
the tool proved it could replace it?
Once I the Affinity tools got to the point that I could do most of what I was doing with illustrator and photoshop then the price made it a no brainer. There were things that I thought Adobe did better but they weren't worth the price - that is, I could accomplish the same thing with Affinity but it took more work and time.
That split - "most of what I was doing" plus a price that makes it
a no-brainer - is probably the clearest description of the threshold
I'm building toward.
I'm not trying to match FreshBooks feature-for-feature. The core loop
has to hold: track the work, create the invoice, record the payment,
keep the records locally. If that covers most of a freelancer's
actual workflow, then some missing features can be reasonable
trade-offs rather than dealbreakers.
And your "it took more work and time" point is important. That's the
part I don't want to hand-wave away. A missing feature is only an
acceptable trade-off if the extra effort stays small enough that the
overall experience still feels better than the alternative.
The $49 only matters after the product proves that. That's why I'm
keeping Early Access deliberately small - I'd rather make the core
loop solid than build a long parity checklist.
What you described gives me a useful test for LockMargin: not "does
it have everything the incumbent has?" but "can someone do most of
their real work with it, and feel that the trade-off was worth it?"
Did that extra effort ever become enough of a problem that you
considered going back to Adobe?
Nope. Never had a reason to go back to Adobe. Affinity could read the photoshop and illustrator files for those times I needed to collab with a designer.
That detail is the whole mechanism. Affinity didn't need to beat
Adobe at everything - it just needed to speak Adobe's language at the
exact point where you touched other people. Reading the .psd and .ai
files meant the switch never stranded a collaboration.
That maps cleanly to invoicing. My equivalent of "reads Photoshop
files" is exports: a PDF any client can open, a CSV any accountant
can pull into whatever they already use. If LockMargin speaks the
incumbent's language at the boundary, the switch becomes permanent
without me rebuilding their whole workflow.
I'm writing that down as a rule: interop at the collaboration
boundary first, parity never.
One last question, since you've lived this: was there ever a moment
where Affinity couldn't open something and the collaboration broke -
or did file compatibility hold every time?
I'd take $49 once over another $19/mo wrapper. The kill I kept hitting was "ChatGPT plus a Google Doc already does this." Recurring rent on that is dead.
One-time also makes the test honest. If nobody buys, you know in a week. A trial can fake life for months.
"ChatGPT Plus + a Google Doc already does this" - that's the honest
objection, and it deserves an honest answer. For a first invoice, yes,
that combo works. What it can't do is be yours. The records live on
two landlords' servers, under two terms of service that can change on
a Tuesday. Stop paying either rent and the system evaporates.
Rent on rent. Your words, not mine - and it's exactly what this whole
project is built to avoid. One purchase, one file on your disk,
readable in ten years with or without me.
On the honest test: yes, and it works both ways. If nobody buys, I'll
know within weeks, and I'll publish that here too. A trial can fake
life for months; a one-time price can't hide at all.
Have you actually run your invoicing through that combo? At what
point did you start wanting something else?
One-time on a local desktop app is the honest price. A subscription only makes sense if you are running servers every month. People can tell when the monthly fee is just there because that is what the SaaS template said.
The part I would watch is support after they own it. With a subscription they can cancel. With a one-time buy they expect it to keep working. How has that felt so far?
You've named the difference that matters most to me. A subscription
customer who is unhappy cancels and disappears. A one-time customer
who is unhappy stays - with the product, and with the resentment. So
the stakes are higher, not lower.
How has it felt? I don't have customers yet, so right now it's
anticipation, not experience. I spent ten years building offline
Windows tools for factories and retail, sold the same way: paid once,
expected to keep working. Those customers taught me the expectation -
when someone owns a tool, "it still works" is not a feature, it's the
baseline.
So support is part of the promise, but with clear edges: bugs in your
version get fixed, and platform fixes stay v1.x forever. I answer
emails myself. Sometimes at 3 AM, sometimes two days late - but I
answer. No SLA, no support team. Just the person who wrote the code.
What's it been like on your end - owning a tool and watching it age?
The part that will matter later is that this is a model decision, not a price decision. A price you can change in an afternoon. A model you cannot, because your v1 buyers bought the promise rather than the number, and moving to a subscription afterwards breaks the exact thing that sold it.
So the asset worth protecting is optionality inside the model you picked. Two shapes that work: paid major upgrades, which is your 50% plan, or the JetBrains variant, where twelve months of updates are included and you keep the last version you paid for forever. Both let revenue recur without renting the software back to the customer.
Practically that means holding entitlements per version from day one rather than a single "is licensed" flag. Retro-fitting that after v2 ships is where the pain lands.
This reframed something for me. "A model decision, not a price
decision" — I was circling around that idea without naming it.
Taking the entitlements point seriously: license tied to the version
you bought (v1 = all v1.x). The 50% major-version discount is a
separate benefit, not the entitlement itself.
I looked at the JetBrains shape. Went simpler: you own what you
bought, forever. Bundling "12 months of updates" puts time into the
purchase — and time is what I'm trying not to rent out.
Your retrofitting warning is the one I'm acting on. This logic gets
built before v1 ships, not invented when v2 money is on the table.
Where would you draw the line between "that's a v1.x patch" and
"that's v2 work"?
The line I would draw is not size of work, it is whose promise the work serves. Anything that makes v1 do what v1 already claimed counts as v1.x: fixes, performance, and keeping up with the operating system. A new capability that changes what the product is for is v2.
The test that settles most arguments: could a v1 buyer reasonably say "I paid for that"? If yes, it ships as a patch.
Two things worth writing down before v2 exists, because afterwards every judgement call drifts toward the paid side. First, platform compatibility stays v1.x forever, otherwise "you own it" quietly means "until Windows changes". Second, publish the rule where buyers can read it. A one-paragraph policy in the licence does more for trust than the 50% discount does, because it is a promise you can be held to.
Good. The clause that pairs with it is the one buyers ask second: what happens if you stop. For local-first software the answer is unusually easy, the copy they hold keeps working without a licence server, and saying that out loud removes the main hesitation people have about buying once from a small vendor.
The place it quietly breaks is activation. 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. Worth deciding now which side of that line you want to be on, because it is a build decision more than a policy one.
"Whose promise the work serves" is a cleaner line than mine.
And "could a v1 buyer reasonably say I paid for that?" - stealing
that test verbatim.
First point: platform compatibility stays v1.x forever. Otherwise
"you own it" silently becomes "until Windows changes" - the exact
drift this project exists to prevent. That goes into the policy.
Second point: already shipped. As of this week the manifesto has
a Principles vs Defaults section and the license has a perpetual-
license clause - the version you bought keeps working, offline,
forever; updates add, they never take away. See
lockmargin.com/manifesto.html#principles-vs-defaults and the license
header. Platform-compatibility line joins it next.
Added a note just above on the piece I would decide before v1: activation. If the licence check ever phones home, even once per machine, then "forever" quietly depends on your servers still answering. For local-first software that is the single line that can undo the promise, and it is a build decision rather than a policy one.
That is the exact line. It's a build decision, and here's which side
I'm on: the license is a signed token. The app verifies it locally
with a public key embedded in the binary. Activation is pasting that
key on a new machine - no server call, no phone-home, not once. If my
servers vanish tomorrow, every copy keeps working. New machines too -
just paste the key.
The trade-off is real, and I've accepted it: without a license server
I can't revoke a leaked key. At $49, a shared key is a cost of doing
business, not an existential threat - and freelancers who track their
own invoices aren't the sharing type. Revocation would mean a
dependency, and the dependency would cost more than the leakage.
The constitution already says "license checks are offline." Your note
makes it code: offline verification, offline activation, no expiration.
That goes into the build spec, not just the policy.
And since this is the second time your comment has changed what I
build - entitlements first, activation now - thank you, plainly. You
read the post more closely than most people write them, and both ideas
are in the decision log with your name on them.
Have you seen a local-only scheme actually ship - or does everyone
add a server eventually?
One time pricing is easy to explain to a person and hard for a model to remember. When someone asks ChatGPT for a freelancer invoicing tool, the named answers are usually the rented ones. Put who it is for on the first screen so there is a slot, not only a line that says no subscription.
Least obvious, most useful point in the thread.
One-time pricing is easy for a person to remember - and surprisingly
easy for an answer engine to miss when the better-known alternatives
are subscription products.
I'm acting on that two ways. First, the pricing model goes on the
first screen as plain facts: "$49 one-time. No subscription. No
account." Second, I publish a machine-readable product summary, so
answer engines get a clean, explicit source to cite instead of
reconstructing the business model from scattered pages. If models still recommend the rented tools, that's fine. But the ownership model shouldn't be invisible because I failed to state it clearly enough.
Do you write product facts differently for answer engines than for
people - or is plain, explicit and repeated still the best strategy?
The interesting part is that the one-time price actually reinforces the product philosophy instead of just being a pricing choice. The real test will be whether customers value ownership enough to accept paying upfront and coming back for major versions later.
I've tried to answer this clearly more than once, and I'm still
trying. Here's where I've arrived so far - not a final answer, just
the current state of my thinking.
The one-time price started as a feeling: charging rent for a tool
whose whole pitch is "don't rent" felt like a contradiction the
customer would feel before they could name it. I still can't prove
the feeling is right. Zero customers so far.
So instead of defending the model, I picked the number that can
disprove it: the major-version upgrade rate - what share of v1 buyers
comes back for v2 at 50% off. If enough do, I'll have evidence the
feeling was pointing in the right direction. If not, better to learn
it early. I'll publish the number either way.
If you've shipped one-time with paid upgrades: what upgrade rate did
you actually get? I'm still forming my expectations - real numbers
would help more than opinions.
That’s an interesting way to frame the test. Publishing the upgrade-rate result either way should make the validation especially useful.
That's the intention, exactly.
The number gets published either way: if the model works, it's
evidence; if it doesn't, it's a lesson. Either outcome should be
useful to someone.
I'll come back to this thread when the first real upgrade-rate number
exists. Zero customers today, so it may take a while - but it will be
here when it does.
That makes sense. Publishing the result either way should make the experiment worth following.
The follow-up is live - "How 30 comments rewrote my software license
before launch." The "publish either way" commitment you pushed for is
written down there.
Honest timing note: the upgrade rate itself can't land in 30 days -
v2 doesn't exist yet. What lands 30 days post-launch is the first
cohort number: how many Start users became Standard customers. You
asked before either existed, so you get it here first.
Your pressure on this made the license boundary clearer than I would
have gotten alone. That wasn't noise.
When the number lands - raw rate, or the cohort breakdown behind it?
The cohort breakdown behind it. The raw rate will show what happened, but the breakdown should make it much clearer where the upgrade behavior is actually coming from.
Cohort breakdown it is. When the number lands, it ships with the cohorts behind it - same page as the commitment.