Shipped a manual net-worth app (no bank sync) — what UX friction would you expect?
I built FiWorth — a simple iOS/Android net worth + goals tracker that stays fully manual. No bank login, no Plaid, no auto-sync.
Why: I kept bouncing off tools that want to connect every account or turn net worth into another budget app. For me the job is simpler — see direction and speed of wealth, and progress toward a number, without giving a third party my bank credentials.
It’s live (v1.1.4). Monetization is soft for now while I collect real usage feedback. Early installs are thin, so I’m short on signal from people who actually care about this wedge.
I’d love blunt UX feedback from anyone who’s built or used money apps:
- On first open, what would confuse you before you’d enter a single balance?
- Is “manual only / no bank sync” a feature you’d trust, or an immediate dealbreaker?
- What missing piece would stop you from updating balances weekly (accounts model, goals, history, currency, something else)?
Product page: https://www.indiehackers.com/product/fiworth
Site: https://www.onemdapp.com
Not looking for growth tips or “just run ads” — specifically first-session and weekly-habit friction.
The drop before the first onboarding step is the most useful data point in this thread. That is not a UX problem — that is a trust problem. Someone downloaded a finance app, opened it, and decided not to enter a single number. The screen they saw was not reassuring enough, or the value proposition was not obvious enough from the first frame.
We made a similar bet with our SEO tool: no signup, no login, no account creation for the free scan. The constraint is the feature. For the people who care about that constraint, removing it would lose them faster than any UX improvement would gain them.
isjackback is right that the spreadsheet is the real competitor, and the way to beat it is not features. It is habit formation. If the app does not pull someone back weekly without a notification, they will go back to the spreadsheet. What does the re-engagement pattern look like after week two?
Manual-only makes sense for the privacy angle, but I’d watch the first balance entry closely. I’d let someone start with a single total + one goal, then ask them to add accounts only after they see a useful projection. For weekly updates, a “what changed since last week?” flow may feel lighter than reopening every account. I’d also explain exactly where the numbers are stored before the first entry.
Good call on the first-entry path. We looked at our onboarding funnel: once people actually hit onboarding, we don’t see a big cliff after the first step. Completion through to the main screen stays pretty flat after the first accounts action. The larger drop is earlier: a chunk of new installs never reach the first onboarding step at all.
So I’m less worried about “make the first balance screen perfect or everyone bails mid-flow,” and more about why some people never start. That said, your “one total + one goal first, accounts later” and “where are numbers stored?” notes are still useful, especially for reducing hesitation before the first entry. The “what changed since last week?” idea I’m keeping for the update habit, separate from first-run.
Appreciate the concrete UX pushbacks.
The manual-only wedge is clear, but it may also be the biggest friction. Have early users actually kept updating weekly without bank sync?
I gotta agree on this one
With manual only your biggest competitor becomes an excel sheet IMO
This is how I do it currently, and I'm not sure what would make me want to change
Fair. Spreadsheet is the real alternative for a lot of people, including me for years.
The only reasons I’d switch myself are: less friction than maintaining the sheet, a clearer path-to-goal picture without building formulas, and a review habit that doesn’t depend on me opening a file I forget exists. If FiWorth can’t beat Excel on those, it shouldn’t win.
Curious what would have to be true in an app for you to leave the sheet - even hypothetically.
Honest answer: I can’t claim that yet. Sample is still small, and retention is the real gap. A lot of people finish first setup, then don’t form a return habit in week one.
Manual-only is the wedge and also the risk. We’re not optimizing for a rigid weekly ritual; we want a sustainable review habit (biweekly or looser is fine). Without bank sync, that habit has to carry the product, and right now that’s what we’re short on evidence for.
If you’ve seen what makes manual money apps stick (or die) after day 0, I’m listening.
Manual entry tends to die for a boring reason: nothing changes between updates, so there is no reward for coming back. A spreadsheet survives that because it computes something you can watch - a rate, a projection - while most trackers just store the number you typed. If two balances turned into "at this pace you reach your target in N months" and you told people up front that biweekly is fine, I would bet the return habit looks different. Curious whether any of your early users update without a reminder - that ratio would tell you if the wedge actually holds.
That’s a sharp cut. Storing the number you typed with no payoff between visits is a boring death.
We do have goals / milestones and a chart, but you’re right that “at this pace you hit the target in N months” (and saying biweekly is fine up front) might be the missing reward loop for return. I’m looking at that.
On the ratio: most early users don’t reliably return without a nudge yet. The ones who do update tend to finish the review once they’re in. So the wedge isn’t proven on unaided habit - reminder + payoff is where I’m poking next.
Manual-only wouldn’t scare me off if the first screen said where the numbers live and that I don’t need every account day one. What kills these for me is update three feeling like retyping homework. Prefill + “same as last time” beats another chart.
The main friction I’d test is not initial entry but remembering what changed since the last check. A lightweight review flow could show each account’s last-entered value/date, offer a one-tap “unchanged” confirmation, and ask for a reason only when the value changes; that preserves manual trust while reducing weekly work. For first-run clarity, show one example asset and a sample goal in the empty state so people understand the payoff before entering real balances.
Manual-only sounds like a trust feature, but I’d want that promise made before the first form. The first-screen friction for me would be not knowing how much setup is coming. A tiny “add one account now, the rest later” path would help. For the weekly habit, I’d also want a very obvious last-updated date plus a nudge only when a balance is stale, otherwise it starts feeling like bookkeeping again.
Manual entry is the whole game then. Biggest friction in
self-tracked apps: the first empty session. If day one shows
nothing but zeroes, people bounce before the habit forms.
Two things that worked in my own tracking experiments:
by week three
Also: how are you handling multi-currency? That question kills more
manual trackers than any UX detail.
The first friction you'll hit is the numbers gap.
Most people know their bank balance and maybe a rough pension number. They have no idea what their assets are worth in real time and resent the reminder that they need to update it manually. The cognitive load of "I need to go find all these numbers again" is what kills the weekly habit.
The insight from financial tracking apps is that people don't actually want accurate numbers. They want a number they can feel okay about checking once a week. Design for the ritual, not the calculation. If updating feels like homework, they'll skip it every time it's not in the green.
The second friction: the first input session. Most people abandon financial tracking tools because the setup asks for everything upfront. Phased onboarding — get them to input one category first, see immediate value, then expand — usually has much better retention than "fill in all your assets before we show you anything."
The no-sync choice could be a trust advantage if the first session explains the update loop clearly. I’d optimize for a 30-second weekly check-in: saved account templates, one-tap “same as last time,” and a prominent last-updated date. A change history or simple trend view would also reassure users that a mistaken edit is reversible without needing bank integrations.
Manual is not the dealbreaker, forgetting is. Every manual tracker I have used died at update three, so the thing to build next is not a feature, it is a ritual: one notification on the same day each month that drops me into a single screen with last month's numbers prefilled so I am editing, not entering. On trust, put what you do not do above the fold (no bank credentials, data stays on device), because that is the only reason anyone picks manual over Plaid and right now you are making people work that out for themselves.
This matches what we’re seeing: setup isn’t the cliff, coming back is. “Died at update three” is exactly the failure mode I’m worried about.
Agree the next bet is ritual more than another feature: a fixed reminder that drops you into last values prefilled so you’re editing, not re-entering. We already lean that way in the update flow (skip / confirm unchanged), but the habit trigger and the “why open today” reward still need work.
On trust: putting what we don’t do above the fold (no bank credentials, data on device) is a fair call. Right now people have to infer that. Taking both points.
I’d question whether weekly updating should be the goal for every balance.
Cash and investments may justify frequent updates, while property, pensions or private assets might only need monthly or quarterly attention. Asking users to re-enter unchanged numbers every week could make the app feel like bookkeeping and create false precision.
I reckon each account needs its own update cadence, with the app showing which values are fresh, stale or simply unchanged. Then the weekly habit becomes “review what may have changed,” not “retype your entire net worth.”
Agree that not every asset needs a weekly touch. Property and pensions shouldn't feel like bookkeeping.
I'm less excited about per-asset update cadences or separate push schedules though. That adds complexity we don't want. Today the update flow already lets you skip steps: you review values and only change what you want. So the product already aims at "review what may have moved," not "retype everything."
The open question for me is whether that flow is obvious enough. If people experience update as mandatory re-entry, that's a communication / UX clarity problem more than a missing cadence engine. Fresh/stale signals might still help as affordances, without turning into per-type automation.
Curious if the skip-and-confirm path would have read that way to you on first use, or if it still felt like full re-entry.
Based on the post alone, the skip-and-confirm path wasn’t obvious to me. “Manual” and “updating balances weekly” made me picture revisiting each account, even if the value had not changed.
So I agree this may be a clarity problem rather than a missing cadence system. Something as simple as “Review complete — 2 values updated, 5 confirmed unchanged” could make the intended workflow visible. Fresh or stale labels might then help users decide where to look without introducing separate schedules.
I haven’t tested the actual flow, though, so I’d treat my reaction as a positioning signal rather than a product verdict.
Helpful - thanks for saying the skip-and-confirm path wasn’t obvious from the post alone. That’s a positioning miss on my side.
“Review complete - 2 updated, 5 confirmed unchanged” is a concrete way to make the intended workflow visible. Fresh/stale as a where-to-look cue (not a per-asset schedule) also fits. Treating your read as a clarity signal, not a full product verdict, as you said.