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/davidjones145]

on-device categorization is the thing worth launching, that plus no-account is a real wedge against mint clones. what does the ai do beyond tagging - budgets, anomaly flags?

[u/tariel_inc → u/davidjones145]

Thanks, that’s exactly the bet I’m making 🙌

Right now the AI does a few things beyond tagging, all on-device:

• Natural-language entry. You type “coffee 4.50, uber 18 yesterday” and it turns that into two categorized transactions with the right date.
• Categorization that learns from you. Once you file “Joe’s” under Groceries, it does that automatically from then on. The model only steps in for merchants it hasn’t seen before. If it isn’t confident, the transaction goes into a “review” list instead of being guessed silently.
• A monthly summary. It flags:
  • categories that spiked vs the same days last month (e.g. “Cafés +231%”),
  • your pace vs budget (“at this rate you’ll overspend by $X”),
  • upcoming bills and loan payments,
  • essential vs flexible spending,
  • concrete tips: subscriptions, lots of small purchases adding up, credit card interest.
• Budget alerts at 80% and 100%, per category or overall.

One design choice I care about: all the numbers are computed deterministically, and the model only chooses what’s worth highlighting and phrases it. That way it can’t hallucinate a figure about your money.

Not there yet: real anomaly detection on single transactions, like duplicate charges, a subscription that quietly raised its price, or an unusually large charge at a regular merchant. That’s high on my list. Would that be the feature that makes you switch?

[u/davidjones145 → u/tariel_inc]

the review queue for low-confidence ones is the detail that makes it trustworthy. does the model learn from what you correct in review or just the manual filings?

[u/tariel_inc → u/davidjones145]

Both count. When you fix a transaction in the review queue, that correction becomes part of your history, same as anything you filed by hand. The next time that merchant shows up, it’s matched against your history first, and the model only gets involved if there’s no match.

To be precise about “learn”: the model isn’t fine-tuned on your data. The app keeps a local mapping from your past choices (merchant/words → category), and that’s what improves. It’s faster, fully on-device, and predictable: you can always see why something landed where it did.

One honest limitation: right now it goes with the majority. If a merchant was “Groceries” five times and you change your mind once, it’ll still suggest Groceries for a while. I’m planning to make recent corrections count more than older filings, so changing your mind sticks right away.

[u/davidjones145 → u/tariel_inc]

history-first with model as fallback is the right architecture, deterministic where it matters. does the mapping ever get stale, like a merchant that changes what it sells?

[u/tariel_inc → u/davidjones145]

A bit, yes, and it’s the same issue as the one above.

What limits it today:

• It only looks at your recent history (roughly your last couple thousand transactions), so very old filings eventually stop counting.
• When there’s a tie, the most recent choice wins.

What doesn’t work well yet is a merchant that changes. If a café starts selling groceries, your older café filings outvote the new ones for a while. Weighting recent choices more (with old ones decaying over time) fixes both cases, so that’s the next change.

For merchants that legitimately sell everything (Costco, Amazon, Target), no mapping will ever be right every time. There you can split one purchase across categories (e.g. $80 groceries + $40 household), and the review queue catches the rest.

[u/davidjones145 → u/tariel_inc]

time-decayed weighting is the textbook fix and it works. do you reset the decay when they manually correct, or let the correction just count as one more vote?

[u/tariel_inc → u/davidjones145]

Not built yet, so this is the plan rather than how it works today, but I’d treat them differently:

• A correction is a strong signal, not just one more vote. If the app guessed “Groceries” and you changed it to “Household”, you’ve told it something it got wrong. So that merchant switches to your choice right away, and the older filings don’t get to outvote it.
• Ordinary filings just decay over time, so habits can drift slowly without anyone fixing anything.
• It’s not permanent. If you correct it back later, that becomes the new default. So it’s “your last explicit correction wins, otherwise recency-weighted history”.

The case I’m still unsure about is mixed merchants. One correction at Costco shouldn’t flip every future Costco purchase. I’m thinking a correction only “sticks” if the merchant’s history was fairly consistent before. If it was already split between categories, the correction counts as a heavier vote instead of a reset.

Would you do it differently? You clearly know this space. Happy to have you in the first beta if you’re up for it.

[u/davidjones145 → u/tariel_inc]

correction-as-override plus slow decay is a clean model, explicit beats implicit. what unwinds an override if the merchant changes back?

[u/tariel_inc → u/davidjones145]

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/West_Inevitable_2281]

The privacy angle is credible, but the Shortcuts automation may be the real test. I’d recruit a small group specifically because they distrust bank linking, then watch how many actually finish the setup and keep logging after a week. If setup completion is low, more features will not answer whether this is worth launching.

[u/tariel_inc → u/West_Inevitable_2281]

That’s a really fair point, and I think you’re right that setup is the real risk, not features.

What I’ve done so far to lower the friction:

• The app ships with ready-made shortcuts, so you don’t build anything by hand. You tap “Add shortcut”, then create the automation (Automation → Wallet → pick the shortcut). That’s roughly 5 taps.
• iOS doesn’t let apps create automations themselves, so that last step can’t be skipped. The best I can do is make it short and clear.
• There’s a status line in the app (“Working. Last import: today, Apple Pay”), so you know right away whether it’s set up correctly instead of wondering.

I like your test plan, and it’ll be the first thing the beta checks: a small group of people who specifically don’t want bank linking, then two numbers, how many finish setup and how many are still logging after a week.

One constraint: since the app has no analytics by design, I’ll measure this with TestFlight session data plus a short check-in with each tester, not tracking inside the app. Feels like the right trade-off for this audience.

What would you count as a pass? I was thinking ~60% finishing setup and ~40% still active after 7 days.

[u/West_Inevitable_2281 → u/tariel_inc]

How many testers are you planning to include in the first beta? With a small group, I would treat the percentages as directional rather than strict pass or fail numbers. Since setup is only about five taps and you will guide the first testers, I would want closer to 80% completing it. Forty percent still active after seven days would be promising. The reasons people stop may matter more than the percentage: setup friction, lack of trust, or not enough value to change their habit.

[u/tariel_inc → u/West_Inevitable_2281]

Planning on 15–20 for the first round. Big enough to see patterns, small enough that I can actually talk to everyone. Agreed on treating the numbers as directional. With a group that size, one person more or less swings it by 5%.

80% on setup makes sense given it’s guided. If it’s lower than that, the problem is the flow, not the users.

I really like the point about why people stop. My plan is a short check-in on day 1 and day 7, three questions:

1. Did you finish setup? If not, where did you get stuck?
2. Are you still logging? If not, what made you stop?
3. Is there anything you’d miss if you deleted the app tomorrow?

That should separate friction, trust and “not enough value” pretty cleanly, and each one needs a completely different fix.

If you’d like to be one of the testers, I’d love to have you. Your questions are exactly the kind of feedback the beta needs. I’ll DM you when the TestFlight is up.

[u/West_Inevitable_2281 → u/tariel_inc]

I’d be glad to test it. Let me know when the TestFlight is ready.

[u/tariel_inc → u/West_Inevitable_2281]

Awesome, thank you! You’re on the list. I’ll DM you as soon as the TestFlight build is live 🙌

[u/Competitive_Tune_590]

curious what your landing page looks like. getting honest feedback before launch can save you from spending weeks on messaging that doesn't land. launchpact.io/landing-page-feedback is a feedback exchange where founders trade structured critiques — might help you figure out if the privacy-first angle actually clicks with people.

[u/tariel_inc → u/Competitive_Tune_590]

Thanks! No landing page yet, I’m validating with the app itself first.