“On-device” is a promise, not a checkbox

Every budgeting app says something about privacy. “Bank-level security.” “We take your data seriously.” Most of it is marketing language sitting on top of an architecture nobody describes. MyBWallet takes the plainer route: your spending entries, your categories and your “Walls” live on your own phone, not on a server we run. That’s not a policy promise written for a privacy page. It’s how the app is built.

What “on-device” actually rules out

“On-device” only means something if it changes what a company can do. For MyBWallet it rules out a few concrete things. There’s no central database of everyone’s spending for anyone to be asked for, lose, or quietly monetise. There’s nothing to sync to an account in the cloud, because there’s no cloud account holding your numbers. If your phone is lost or reset, your budgeting history goes with it — the same trade a paper notebook makes. That last part is the honest cost of the promise, not a footnote we’d rather leave out.

Why a spending Wall doesn’t need a server

A Wall is a hard ceiling you set per category — food, rides, fun, whatever matters to you. Checking whether you’re under it is arithmetic: add up what you’ve spent this month, compare it to the number you set. That calculation runs on the phone the moment you add an expense, not on a request sent somewhere else and waited on. The feature that matters most — “you’re about to cross a line” — was never a feature that needed a network call in the first place. Keeping the data local isn’t a restriction bolted on afterwards; it’s simply where the calculation always lived.

A policy is a promise about behaviour. A design is a promise about capability

A privacy policy says: “we won’t do X.” A design says: “we can’t do X, because there’s nowhere for X to happen.” The first can change with a new owner, a new feature, a new business model, and a single updated paragraph. The second usually can’t, not without rebuilding the app from the data layer up. When you’re weighing any app that claims to be private, it’s worth asking which kind of promise it’s actually making. If the answer only lives in a policy document, treat it as marketing until it’s shown to be more. If it’s visible in what the app can and can’t do — no account to create, no sync to switch off, nothing to request under a data law because nothing was collected centrally — that’s a claim closer to something you can actually rely on.

What this looks like day to day

None of this needs to feel technical to use. You add an expense and it takes seconds. You set a Wall for a category and the app shows you how full it is, no separate sync step, no spinner waiting on a connection. Get close to a limit and you get a quiet nudge, not a lecture. At the end of the month you see the shape of your spending without opening a spreadsheet. The privacy sits underneath all of that, doing its job quietly; you don’t have to think about it to benefit from it.

A privacy claim you can’t verify is a sentence. A privacy claim built into the architecture is a fact about what the software can and can’t do.

Where to start

This is what MyBWallet is built around: your numbers stay yours, and the Walls hold without a server watching over them. Have a look at MyBWallet for yourself, or talk to us if you have questions about how we handle data on any product we build.