Why I’m charging a $19 one-time fee instead of building a $10/mo SaaS
The internet is suffering from massive subscription fatigue, and I think the personal finance space is the worst offender.
When I looked around at the budget and wealth-tracking tools on the market, almost every single one of them wanted $10 a month. Even worse, to justify that recurring revenue, they practically demand your Plaid credentials so they can constantly scrape your banking history and store your financial telemetry on their cloud servers.
I realized there is a massive, underserved market of developers and privacy advocates who want the premium visualizations of a startup (like automated Sankey cashflow diagrams and FIRE projections) but flat-out refuse to give up their data sovereignty or pay forever.
So, I built FinFortress. Instead of spinning up a cloud database and locking features behind a monthly login, I’m distributing it as a local .zip file. The user downloads it, clicks a start.bat script, and runs the Python application entirely on their local machine. No APIs, no telemetry, no subscriptions. Just a $19 one-time fee for the software.
It’s definitely a terrifying pivot away from the holy grail of MRR (Monthly Recurring Revenue), but I think the trust it builds is worth it.
I’m curious to hear from other builders here: Have you noticed a shift in your users preferring offline, locally-hosted desktop apps over traditional SaaS? Is the "Anti-SaaS" model actually a viable long-term business?
I’m testing the same one-time logic at $9 for a browser grader, and the question I keep coming back to is not MRR versus one-time. It is what maintenance burden the buyer expects after purchase. Your ZIP is local, but it depends on Python, scikit-learn, and bank CSV formats. I would make the update policy explicit: which environments and files are supported, whether future fixes are included, and what happens when a bank changes its export. That makes $19 feel like ownership rather than unsupported software.
You hit on the absolute biggest risk of building an offline finance app. I realized early on that if I hard-coded bank CSV formats, I would be stuck doing 'subscription-level' maintenance forever just fixing broken imports.
My solution was to push the configuration to the user via a simple
settings.yamlfile. The app uses a 'synonym matching' system for column detection. If a bank suddenly changes their export column from 'Buchungstag' to 'Datum', the user doesn't need to wait for me to push a software update-they just open the YAML file, add 'Datum' to the list of date synonyms, and the app instantly fixes itself. Making the software 'self-healing' by giving the user access to the configuration is the only way a one-time price model survives long-term!Privacy-conscious users being tired of handing banking credentials to cloud tools is a real and specific frustration, that's a much sharper wedge than "cheaper than a subscription." The maintenance question in the comments is the real risk though, a one-time purchase with an expectation of ongoing CSV format support is a subscription's workload without a subscription's revenue. Have you thought about how you'd handle that long term, or is it too early to worry about that yet?
You hit on the absolute biggest risk of building an offline finance app. I realized early on that if I hard-coded bank CSV formats, I would be stuck doing 'subscription-level' maintenance forever just fixing broken imports.
My solution was to push the configuration to the user via a simple
settings.yamlfile. The app uses a 'synonym matching' system for column detection. If a bank suddenly changes their export column from 'Buchungstag' to 'Datum', the user doesn't need to wait for me to push a software update-they just open the YAML file, add 'Datum' to the list of date synonyms, and the app instantly fixes itself. Making the software 'self-healing' by giving the user access to the configuration is the only way a one-time price model survives long-term!Pushing the column-mapping logic into a user-editable YAML file instead of hard-coding bank formats is a genuinely smart way to dodge the maintenance trap a one-time price model usually falls into. The synonym system means the fix lives with the user the moment it's needed, instead of queuing behind your own release schedule. Have you seen non-technical users actually comfortable editing that file themselves, or does it end up being more of a power-user escape hatch?
Honestly, because the current marketing leans so heavily into Python, offline architectures, and data sovereignty, the early adopters are almost entirely developers, data nerds, and power users. For that crowd, editing a YAML file is basically second nature, so it works perfectly as an escape hatch.
To help the less technical folks, I made sure to include a highly visual, copy-paste section in the Launchpad PDF manual showing exactly how to open and edit the file safely without breaking the formatting.
Makes sense that the current audience is developers and data nerds first, the marketing itself is doing that filtering before anyone even gets to the YAML file. The visual copy-paste guide in the manual is a smart bridge though, it means you're not fully locked out of less technical users, just making the technical ones the easier default. Once you do get more non-technical buyers, will the config system need a real UI, or is the manual enough to hold that gap for now?
I made the same call for a Mac app, and the rule I landed on is basically a fairness line: charge once when the value lives entirely on the user's machine, and only subscribe when there's an ongoing service on your side (sync infra, an API you pay for, a backend doing real work for them month to month). A local .zip is squarely the first case, so $19 once isn't just cheaper, it's the honest price. Charging rent for software I'm not even hosting never sat right with me, especially for a small tool people open every day. On the "it doesn't compound" worry a couple of people raised: a paid v2 people are happy to buy again covers that without pretending it's a service it isn't.
The 'fairness line' is a brilliant way to frame it. That completely articulates what I was feeling but couldn't put into words. If there is no ongoing cloud infrastructure, API cost, or server compute happening on my end, charging monthly feels like extracting rent rather than providing value. I'm definitely adopting that fairness line philosophy moving forward. And you are spot on regarding the v2 approach-major architectural upgrades warrant a new purchase, but the core tool should just work.
One angle nobody's mentioned yet: distribution. SaaS has SEO, app stores, and can show up in product hunts because it's cloud-hosted. A .zip file is harder to discover - people have to already know to search for "offline personal finance" and trust a random download. How are you thinking about getting this in front of people who've never heard of it? That gap between building something trustworthy and making sure people can actually find it is often the hardest part of the one-time model.
Distribution is absolutely the hardest part of the Anti-SaaS model. Without MRR to fund paid ads, the strategy has to be 100% organic and engineering-focused.
My main funnel right now is technical content marketing. I'm writing deep-dive architecture articles on my blog about how to build local machine learning classifiers and Streamlit dashboards, which brings in high-intent SEO traffic from developers. I also hosted a read-only demo of the UI on a free Streamlit Cloud tier, linked from a public GitHub repo. It gives people that 'SaaS discovery' experience online, and then the README funnels them to Gumroad to buy the actual offline, local-compute package.
This is a brilliant positioning. The psychological difference between 'renting' a service for $10/mo forever versus 'owning' a tool for a $19 one-time fee is massive, especially in the personal finance space where trust is already fragile. I have definitely noticed a shift. People are becoming hyper-aware of how their data is monetized. By removing Plaid and cloud telemetry, you’re turning a major pain point of traditional SaaS into your strongest unique selling proposition (USP). The biggest challenge with the Anti-SaaS model isn't viability, it's acquisition. Without recurring revenue to fund long-term CAC (Customer Acquisition Cost), you have to rely heavily on community building, word-of-mouth, and transparent marketing (exactly like this post!). Really respect the bold move.
You nailed the exact psychology behind the positioning. In a space as intimate as personal finance, 'renting' your own data back from a cloud provider inherently breeds distrust. Realizing that I could take the biggest missing features of traditional SaaS-the lack of Plaid, the lack of cloud sync-and turn them into the core USP was the lightbulb moment for this project.
You are 100% right about the CAC challenge, though. When customer lifetime value is permanently capped at $19, paid ads are basically off the table. The entire acquisition strategy has to be built on organic trust: posting transparent teardowns like this one, writing open-source technical deep dives on my blog, and relying heavily on word-of-mouth in the FIRE and privacy communities. It’s a much slower burn than pumping money into standard ads, but the users you acquire this way are infinitely more loyal. Really appreciate the respect!
On your actual question — is Anti-SaaS viable long-term — the trust case is strong, so I'd just flag the one thing the model quietly changes: one-time revenue doesn't compound like MRR. With a subscription, last month's buyers still pay this month; at $19 once, every month restarts at zero, so you're finding brand-new buyers forever just to stay flat. Still very viable — but the one-time businesses that last usually lean on paid major upgrades (a v2 people happily buy again) rather than pure one-and-done. That's probably the piece worth thinking through while the trust story is doing the selling for you.
This is the exact trade-off I had to make peace with. Waking up on the 1st of the month at $0 revenue is definitely the scary part of ditching MRR. But leaning into the 'Paid V2' upgrade model (exactly like the classic software days of buying a new version of Windows or Photoshop every couple of years) feels like the healthiest compromise. The trust story makes the initial sale, and continuous, major feature development earns the V2 upgrade down the line.
Trust makes the sale, feature development earns the upgrade' is a great way to put it — good luck with it
I agree, it seems everyone just defaults to "monthly payment". For a zip file, there's no reason to have a monthly price. I've been doing the same thing with my product (web to mobile boilerplate, shipped as a zip) and I have to say, it's much easier to market it as "one time purchase, use forever" rather than "pay me monthly"!
Exactly! There is something incredibly freeing about just selling a piece of software and telling the user, 'Here is the zip file, it's yours forever.' It forces you to build a complete product from day one rather than shipping an MVP and promising to finish it using their subscription money.
The pricing logic is sound. I wouldn't second-guess $19 one-time for a privacy/FIRE audience. What I'd watch is the first-run: asking a security-conscious user to unzip and run a
start.batwith a Python dependency is a real trust-and-friction paradox for exactly the people you're courting, and that download-to-first-Sankey moment is probably costing more conversions than the price is.A signed, single-file build they can inspect (or a clear "here's every line that runs locally") would let the privacy story close the sale instead of tripping on setup.
Given your audience, your best-converting content might be posts exactly like this one, are FIRE/privacy communities where you're focusing distribution, or somewhere else?
You nailed the paradox perfectly: the exact people who care the most about privacy are the ones most suspicious of running a .bat file!
To mitigate this, I intentionally left the Python code completely uncompiled and open. It is not a black-box .exe. Privacy advocates can open any file and the local ML scripts in any text editor and see exactly what is running (and verify that there are zero external API calls). I also included a highly detailed PDF manual in the zip that walks them through the Python environment setup step-by-step so the 'download-to-Sankey' pipeline is as smooth as possible. But you are right-nailing that first-run experience is the next major hurdle.
What's interesting isn't the $19 one-time price—it's that you've made your revenue model reinforce your trust model. I'd keep validating whether customers buy FinFortress because it's cheaper than SaaS, or because paying once and keeping complete control of their financial data feels fundamentally more aligned with what they're trying to protect.
'Making the revenue model reinforce the trust model' is exactly what I was aiming for, even if I didn't have that exact phrasing for it until now!
My working hypothesis is definitely the latter. The people in the FIRE and developer communities aren't necessarily opposed to spending money on good tools, but they are fiercely protective of their data sovereignty. If I charged a subscription but claimed the app was 'local first,' there would always be that lingering technical doubt: Why do they need to ping my machine every month if it's truly offline?
The one-time
.zipdownload is the ultimate proof that the cord is fully cut. You make a great point about validating this, though. I am definitely going to pay close attention to the early user feedback to see which angle (cost vs. control) is actually driving the most conversions. Thanks for framing it this way!Appreciate the context.
The distinction you're testing between cost and control is exactly the interesting part, but I don't think I'd do it justice in a public thread.
If you're open to it, what's the best email to reach you on?