Why I'm not adding bank linking to Penno (ever)
The case in one line: Adding bank linking would turn Penno into a different product — one with servers, accounts, an aggregator dependency, and a different privacy story. That's not the product I want to build, and I think the no-bank-linking version has a permanent niche worth filling. Here's the full argument.
Bank linking is the most-requested Penno feature. I get the email roughly once a week: "Could you add Plaid? It would save me 20 minutes a month." The honest answer is no. Not "no for now" — no, period.
Most developers don't say "ever" about feature requests. The default posture is "noted, on the roadmap." Saying "ever" closes a door I might want open later. I'm saying it because the door being closed is part of the product.
What bank linking would change
Adding Plaid (or equivalent) to Penno would require:
- A user account system (Plaid needs to associate token+user; tokens need to refresh)
- Backend infrastructure (Plaid's API can't be called directly from a mobile app for security reasons; you need a server to mediate)
- An ongoing aggregator subscription fee (Plaid charges per account per month — passes through to user prices)
- A larger privacy policy (now I'm a custodian of transaction data, even briefly during refresh)
- SOC 2 or equivalent compliance work (handling that data is regulated)
- A different business model (the per-account fee structure forces subscription pricing)
Each item alone is manageable. Together they redefine the product. The "local-first, no servers, no subscription, no account" pitch is gone — not because I broke a promise, but because the architecture changed.
The user who wants both
The user emailing me about Plaid usually wants both: the privacy of local-only storage AND the convenience of automatic import. I get it. I'd want both too if they could coexist. They can't.
The transaction data has to come from somewhere. If it comes from your bank via Plaid, Plaid sees it. If Plaid sees it, the privacy claim "no third party sees my transactions" stops being true. There's no way to add bank linking without breaking the claim, because the claim is about the absence of a third party, not about how trustworthy the third party is.
If your priority is convenience, Copilot Money or Monarch is the answer. They're great products, built honestly around the bank-linking model. I recommend them in our comparison pages. The convenience does cost something — money and data sharing — but if the trade is worth it for you, take it.
If your priority is the no-third-party claim, Penno is the answer. The trade-off is manual entry. The decision is yours.
The market for "no bank linking" is permanent
A meaningful number of people will always reject bank-account integration with budget apps. They have varied reasons:
- Privacy-conscious users who don't want any third party in their finances
- Users in countries where Plaid coverage is poor or nonexistent
- People burned by previous account aggregator outages
- Folks who tried bank-linked apps and found the data flow uncomfortable
- Users who use cash or non-mainstream banking (credit unions, neobanks) where Plaid coverage is inconsistent
- People who want the friction of manual entry as a behavior-shaping feature
This isn't a vocal minority — it's a permanent cohort. Mint had 25 million users at its peak, of whom probably 1-3 million would have preferred a no-bank-linking option if it existed. Penno doesn't need 25 million users. It needs a few thousand of the no-bank-linking cohort to be sustainable as an indie business.
The architectural integrity argument
Penno's claim isn't just "we promise not to misuse your data." It's "we can't misuse your data because we don't have it." That's a stronger claim, but only because the architecture enforces it.
The moment I add a server-mediated bank-linking flow, I have transaction data — even briefly, in transit. Now my privacy claim depends on policy, not architecture. Policies change. Architectures don't change as easily.
I want users to be able to look at the binary and verify the claim independently. App Store privacy listing: no data collected. Plaid SDK: not in the binary. Source-code-level claims: verified at /claims. Adding bank linking breaks every one of those verifications.
The slippery slope is real
If I added Plaid integration, the next email I'd get is "Could you add cloud sync between my phone and iPad?" Then "Could you add shared budgets with my partner?" Then "Could you add a web client?"
Every one of those is reasonable. Every one requires more server infrastructure. Every one moves Penno toward the architecture I started against. Six iterations down the road, Penno is Monarch with worse design.
The way to not slide down a slope is to not step onto it. So I'm not stepping on.
What I'll do instead
Make manual entry faster and more pleasant. iOS Shortcuts for one-tap logging. Better widget integration. Faster onboarding for the categories most users actually want. Optical character recognition on receipts (entirely on-device, using Apple's Vision framework — no data leaves the phone). Better CSV import for users who want to bring in historical data from another app.
None of these touch the architectural integrity. All of them reduce the friction that's the central complaint.
If you really want bank linking
Use a different app. Copilot Money and Monarch Money are both excellent and I link to them in our comparison pages without snark. They cost more than Penno and they have the architecture for what they're doing.
What I won't do is build a Frankenstein hybrid that promises both and delivers neither.
— [Founder]
Subscribe to The Quiet Finance Letter
One essay every 3–4 weeks. Privacy, indie software, and the budget-app industry. No tracking pixels. Unsubscribe with one reply.
Subscribe via email →Opens your mail app. We add your address by hand — no tracking, no double-opt-in spam.