There was a specific Tuesday in 2023 when I cancelled an invoice OCR subscription, sat with it for about a day, and then started sketching what would eventually become JuSenseSheet.
Nothing dramatic had happened. I hadn't been wronged by the company. The software worked fine. I just noticed, on the monthly billing email that morning, that I'd now paid roughly $480 over the past year for a tool I opened about twice a week, primarily to turn a PDF into a spreadsheet row or two. That worked out to about $4-5 per use. Which is fine, if the alternative is something catastrophic. But the alternative was just doing the same thing myself in 15-20 minutes by copy-pasting. So what I was actually paying for was the time saved. Which was real. But when I worked out the hourly rate that implied, it was absurdly high for the task.
And the subscription would keep compounding. Five years of that, which is roughly how long I imagine doing my own books, would be $2,400. For a task that is genuinely not complicated.
I'd been meaning to build something small, personal, and not another SaaS subscription for a while. This felt like the right first candidate.
Why bookkeeping, specifically
I was doing the books for two small companies I run — nothing exotic, just the normal cadence of invoices coming in, expenses to categorise, month-end reconciliation, quarterly filings. The actual bookkeeping work isn't hard. What eats the time is the friction at the edges: getting data out of PDFs and into something structured.
And it turned out the friction had a shape I recognised from other product work: lots of small, repetitive transformations, each of which is individually cheap but collectively miserable, which means almost anyone willing to pay will pay a lot to make them go away. That's a market. It's also — I'd notice later — a market where nearly every existing product charges by the month rather than the transformation, which felt like a category-wide business decision more than a technical necessity.
I also liked that bookkeeping is an unglamorous category. No AI demos on Twitter, no VC-funded launch parties. Just accountants quietly doing their work, noticing when tools respect their time and budget. The customer I wanted was a solo bookkeeper handling ten or twenty client books, who was the same kind of person I am — someone for whom a $40/month line item they barely use starts to bother them after a year.
The architectural decisions, in order
Once I decided to build something, there were three forks in the road that I think most people default one way on and I went the other. They compound into the whole character of the product.
Fork 1 · Cloud vs. local
Every competitor I looked at uploaded the invoices to their servers and did the OCR there. This is the default because server-side OCR is easier to build, easier to improve over time, and lets you charge a subscription for the ongoing compute.
I went the other way, and the reason wasn't technical — it was that I kept thinking about my accountant friend Priya who handles books for a few local doctors and a lawyer. Her clients' invoices have patient names on them. Or client settlement amounts. Or billing addresses tied to active legal matters. "Just upload them to a US cloud service" is not a conversation she wants to have with those clients. It isn't really a conversation I wanted to have either, for my own books.
So: browser-based extraction, using PDF.js (Mozilla's JavaScript PDF parser) plus a custom layout parser I wrote for invoice structure specifically. Storage in IndexedDB, AES-256-GCM encrypted at rest, keyed locally. Nothing uploaded. If the app works at all, it works because it isn't calling any server you don't know about.
This cost me a lot of development time. Server-side OCR is a library call; browser-side OCR is actually engineering. I don't regret it.
Fork 2 · Subscription vs. one-time
This is the one everyone asked me about when I was talking to other indie founders. "Why one-time? You're leaving recurring revenue on the table." Yes. I know.
The reasoning I kept coming back to: subscription pricing is correct when the vendor is continuously delivering value — servers that run, updates that ship, support that's available. For JuSenseSheet, the vendor isn't delivering any of those continuously. The app runs on your device. Updates happen when I push them, which might be every three months or every year. Support is a handful of emails a week. The delivery model doesn't match the pricing model.
What a subscription would really be paying for, in this category, is your ongoing permission to use software you already installed. That is a weird thing to be paying for. It's not nothing — the vendor could walk away tomorrow and that'd be bad — but the fix to "vendor could walk away" is to make the software not depend on the vendor existing, not to force customers to keep paying so the vendor has an incentive to survive.
$39 one-time. Lifetime license. Works on every device. The main cost for me is forecasting: I don't get the smooth MRR graph every SaaS founder memes about. That's a trade I chose.
Fork 3 · License server vs. honor system
This is the one people push back on the hardest, so I'll spend a moment on it.
JuSenseSheet license validation is entirely offline. The app checks the format of your key locally, and if it looks valid, Pro features unlock. That's it. There is no JupiterSense license server. The app never calls home.
Yes, this is technically crackable. Anyone reasonably motivated could figure out how to generate a working-looking key without paying. I know this and chose it anyway.
Here's the reasoning. Any license server I'd set up would have three consequences:
- It becomes a dependency that has to keep running forever. If JupiterSense closes, the license server goes down, and every paying customer's app stops working. That's worse than piracy risk.
- It creates telemetry I don't want. Every license check is a phone-home. Even if I promise not to log it, the network request itself is visible — any privacy-conscious customer would notice and lose trust. My whole positioning falls apart.
- The target market is solo bookkeepers paying $39 once. The effort-to-reward ratio for pirating this specific product is poor. People willing to read an entire privacy-first marketing page and buy my tool are not the same population as "will spend two hours to avoid a $39 charge."
So I made the trade: some fraction of a fraction of users might use the app without paying, and in exchange, every paying customer gets a product that doesn't phone home and keeps working forever. On the math of what protects trust versus what extracts it, honor system wins clearly.
The first paying customer
She was a bookkeeper in Bristol who ran her own practice — seven regular clients, a mix of small retail and two professional services firms. She'd been paying for Hubdoc via her Xero subscription for four years.
She wrote me a three-paragraph email about two weeks after buying Pro. The paragraph I keep coming back to was: "It felt weird the first day, processing invoices without something asking me to log in. Then by the third day it felt correct, and by the second week I realised I'd forgotten what the old workflow was like."
That's worth more than any marketing copy. If I never made another sale I'd still frame that email.
What I'm still figuring out
Shipping this has been clarifying about some things and confusing about others. Clear: the architectural choices were right for the category and the user. Confusing: how to grow a product like this without falling back into SaaS-shaped marketing patterns that don't fit.
Most of the growth-hacking advice available to founders is optimised for subscription economics. Free trials that auto-convert, onboarding optimised for "time to first subscription," churn-reduction playbooks. None of that applies when the product is $39 once. What matters for one-time pricing is more old-fashioned — genuinely useful content, word-of-mouth from bookkeepers who liked it, review pages and directories that accumulate authority over time.
That's also a slower game. I accept that.
One thing I'd tell another founder considering a one-time-pricing product:
The hardest part isn't the pricing decision. It's resisting the gravitational pull back toward subscription thinking every time growth gets hard. Every time traction stalls, there's a voice saying "add a cloud tier, add a pro+ tier, add something recurring." Sometimes those voices are right. Mostly they're the defaults you started out deliberately not using.
What the product is now
As of this writing, JuSenseSheet is at version 3.3.7, does everything I need for my own books, and is starting to get used by other people. Free tier handles 50 invoices a month indefinitely, which is genuinely enough for solo business owners and very small practices. Pro is $39 one-time.
I still use it myself for the books of the two companies I mentioned at the top. That matters to me — I don't think you can build tools for bookkeepers without being one in some capacity. When I notice a friction point in my own Tuesday-evening reconciliation, that's usually the next thing I ship.
If this resonates and you want to try it, the free tier is at jupitersense.com/app. If it doesn't fit your workflow — no worries. Use whichever of the alternatives I compared last week fits better. I'd rather have you on the right tool than the one I happened to build.