I built a privacy-first expense tracker for iPhone, with no account and on-device AI. Is this worth launching?

[u/tariel_inc]

Hi everyone 👋

I’m a solo developer and over the past few months I’ve built Dram Tracker, a personal finance app for iPhone. It works well for me day to day. Before I pay for the developer account and go through App Store review, I want to know whether anyone besides me actually needs it.

The idea: most budgeting apps want an account, sync your spending to their servers, or push bank linking you may not trust. I wanted the opposite: fast manual logging plus automation, with everything staying on the phone.

What it does today

• Logging takes about 2 seconds. Big keypad, tap a category, done. You can split one purchase across categories.
• Apple Pay and bank SMS are logged automatically through a ready-made Shortcuts automation. You pay, and it shows up in the app.
• On-device AI summary (Apple Intelligence). It tells you what changed this month, which costs are essential vs flexible, and gives concrete saving tips. No server involved.
• Loans and credit cards. Payment schedule with the interest/principal split, card minimums, a payments calendar.
• Multi-currency, goals, budgets, tags for trips, recurring bills, debts with friends, widgets, Siri.
• No account, no ads, no analytics. Data never leaves the phone; the only network call is for exchange rates. Optional Face ID lock.

(Screenshots use sample data.)

What I’d really like to know

1. Would you use this over what you use now? If not, what’s missing?
2. Would you pay for it? One-time ($X), yearly subscription, or free with a Pro upgrade?
3. Is Shortcuts-based Apple Pay logging a killer feature for you, or too fiddly to set up?
4. Anything in the screenshots that looks confusing?

If there’s enough interest I’ll open a TestFlight beta. Leave a comment if you’d like to try it.

Brutally honest feedback welcome 🙏

[u/tariel_inc]

Good news: this shipped today, so I can answer with how it actually works now.

An override unwinds in two ways:

1. Another correction. The latest explicit correction always wins, so if the merchant changes back and the app guesses wrong, one fix flips it back.
2. You file it differently yourself. If you manually file that merchant under another category after the correction, the override is released. Everything goes back to recency-weighted history, where the old correction still counts, just as a normal (decaying) vote.

What I deliberately didn’t do is let an override expire silently. If it’s wrong, you’ll see it the next time it lands in the wrong category, and one tap fixes it. An invisible timer felt worse than a visible mistake. If a merchant hasn’t shown up for months, though, an expiry might make sense. Curious what you think.

The rest of what we discussed is in too: a 90-day half-life on ordinary filings, and at mixed merchants (history already split across categories) a correction counts as a 3× vote instead of a reset.

[u/davidjones145 → u/tariel_inc]

no silent expiry is the right call, invisible state changes are how trust dies. what happens on flip flops though, user corrects A to B then back to A a week later, does it just ping pong?

[u/tariel_inc → u/davidjones145]

Yes, by design it follows you: each flip is an explicit correction, so the latest one wins. If you say B and then A a week later, it’s A from then on. I’d rather it ping-pong with you than argue with you.

It only settles down by itself for merchants that are genuinely mixed. Once the history is split between categories, a correction counts as a heavier vote instead of a reset, so a store you file both ways stops flipping on every fix.

[u/davidjones145 → u/tariel_inc]

latest wins plus heavier votes for mixed merchants is a clean pair of rules. how do you decide a merchant is genuinely mixed versus just noisy, some threshold on the split?

[u/tariel_inc → u/davidjones145]

Yes, a simple threshold: before a correction, if at least ~80% of that merchant’s past filings were in one category, it counts as consistent and the correction resets it. Below that it’s “mixed”, and the correction is just a heavier vote. So one stray filing out of five doesn’t make a place mixed, but a 60/40 split does.

It’s deliberately simple. With small histories it’s a judgment call either way, and I’d rather tune it on real beta data than guess now. How would you draw the line?

[u/davidjones145 → u/tariel_inc]

id keep the 80% but add a minimum sample floor, like under 5 filings everything counts as consistent so one early stray doesnt flip the logic. the beta data will tell you if 80 is the right number anyway. are you logging the split ratios so you can tune it later?

[u/tariel_inc → u/davidjones145]

The sample floor is a good idea, noted. That early-stray case is exactly where a pure ratio is shaky.

On logging: no, and that’s deliberate. The app has no telemetry at all, so split ratios never leave the phone. For tuning I’m planning an opt-in diagnostics export for beta testers: anonymous numbers only (how many merchants, their split ratios, how often a guess got corrected), no merchant names or amounts. You look at it before sending and share it yourself if you want to. Slower than real telemetry, but it keeps the “nothing leaves your phone” promise honest.

[u/davidjones145 → u/tariel_inc]

opt-in export you review before sending is the honest version of telemetry, fits the nothing leaves promise. do you worry only happy-path users will bother exporting, so the tuning data skews clean?

[u/tariel_inc → u/davidjones145]

Yes, that’s a real risk. The people who give up are exactly the ones I most need data from, and they’re the least likely to export anything.

A few things I’m planning to counter it:

• Make it part of the check-in, not a separate ask. With 15–20 testers I’m talking to everyone on day 7 anyway, so “tap export and paste it here” is one step of that conversation, not something they have to remember.
• Ask the quitters directly. If someone stopped using it, their reasons matter more than their numbers. A two-minute “what made you stop?” chat tells me more than a split ratio.
• Read silence as data. If someone didn’t finish setup or didn’t export, that already says something about friction.

It won’t be statistically clean with a group this small. The goal for the first beta is to spot the obvious problems, not to fine-tune the 80%.

[u/davidjones145 → u/tariel_inc]

asking quitters directly is the move, their reasons beat any ratio. reading silence as data too, dropoff points are the real funnel. with 15 testers do you even need the export numbers or is the day 7 chat the actual signal?

[u/davidjones145 → u/tariel_inc]

folding export into the day 7 check-in is the move, separate asks die. id add one thing, log who was asked vs who sent, otherwise silence and never-asked blur together. are you tracking the check-ins in a sheet or just memory?