Shipped a manual net-worth app (no bank sync) — what UX friction would you expect?

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.

The manual-only wedge is clear, but it may also be the biggest friction. Have early users actually kept updating weekly without bank sync?

The first FiWorth friction may not be your opening screen. It may be the narrower question underneath it: who specifically wants to track net worth manually because the app never touches their bank credentials?

You have shipped v1.1.4 on iOS and Android. FiWorth tracks net worth and goals without bank login, Plaid, or auto-sync. You built it because tools that asked you to connect every account, or turned net worth into another budgeting app, made you bounce. Monetization is intentionally light while you collect real usage feedback. Early installs are thin, so you do not yet have enough signal from people who care about that wedge.

Your UX questions are reasonable: what confuses someone before the first balance is entered, whether manual-only is trusted or an immediate dealbreaker, and what stops a weekly update habit. But with thin installs, those questions may be impossible to answer cleanly. A confusing first session for the wrong visitor may not matter; a clear first session for a person who never wanted manual tracking may still produce churn.

The first risk is audience definition. “People who want to track net worth” is too broad. The sharper group is probably people who already track assets manually, dislike giving bank credentials to a third party, and want direction, speed, and progress toward a target rather than another budgeting system. If you cannot find at least ten people matching a definition like that within two or three weeks, the product is not yet attached to a reachable audience.

The second risk is the meaning of manual-only. Your own history supports it: you kept bouncing off account-linking tools. But that is founder evidence, not user evidence. Manual-only becomes a real wedge only if users choose it despite the cost of entering balances. If early users leave before onboarding, or if they say they prefer automatic sync, then “no bank connection” may be a constraint you love more than they do.

The third risk is the weekly return. Manual trackers often die when updating feels like repeated homework, so “what stops weekly updating” may matter more than first-open polish.

So I would pause interface changes for a short test. Write one narrow definition of your intended user. Then manually find ten people who fit it. Ask only about past behavior: what they use now, what they used before, whether they have paid for a comparable tool, and where they already discuss this problem.

Then invite up to five of them through the first balance-entry flow. Watch where they hesitate, whether they finish the first entry, and whether they return for a second update without a reminder.

Spend two to three weeks and five to ten hours per week. Treat the test as successful if you find ten fitting people, at least three have paid for a comparable tool before, and at least five come from one place you can reach again. If you cannot build that list, or nobody has ever paid for a comparable solution, freeze new UI work and sharpen the audience definition first.

A few answers would make this much clearer: How many installs, first opens, first balance entries, and second updates do you have so far? Has anyone returned without your prompting? Has anyone specifically said manual-only is why they chose FiWorth? What did they use before, and have they paid for it?

These observations come only from what you publicly wrote. This is a scored diagnosis under uncertainty, not a verdict; validation changes confidence, not certainty, and the decision remains yours.

The “no bank sync” promise is clear, but the first-session question may be whether users understand the update loop before entering all their accounts. I would show one sample balance and let someone complete a review with “unchanged” confirmations, then measure second-update completion separately from onboarding completion. Would you rather optimize for weekly updates or make a monthly review the default so manual entry does not feel like bookkeeping?

I work on the opposite side of this (a transaction app that does link banks), so here's the view from there.

Manual only is a feature in my book. Bank linking is where most of the trust friction lives, so "your credentials never touch us" is a real hook for people who care about that. Just say it in the first five seconds, not buried in a settings page.

First open: before anyone enters a balance they need to see what the finished screen looks like. A sample net worth chart with demo numbers they can clear beats an empty state asking for data.

Weekly updates: the risk isn't onboarding, it's week three, when updating balances starts to feel like homework. I'd design around a monthly check-in instead of a daily habit: one screen listing every account with its last-updated date, a quick "still accurate?" tap, and a trend line that visibly moves when you update. The line moving is the reward.

Also worth testing: CSV or paste import. It keeps the no-bank-login promise but saves people from retyping ten accounts on day one.

You mentioned opens are mostly reminder-driven so far. I'd make the reminder carry the payoff ("2 minutes to see how your net worth moved this month") instead of a generic nudge.

That distinction helps: finishing an update and choosing to come back are different problems. Do you know what usually prompts someone to start a re-evaluation—an external change, a reminder, or checking progress on their own?

If the larger drop happens before the first onboarding step, the friction may be trust rather than data entry. A money app is asking for sensitive numbers before the user has seen any value. Have you tried an interactive sample portfolio first, then asking them to create their own only after they understand the weekly view? I'd compare sample opened, onboarding started, and second update completed to see where trust turns into a habit.

Friction measures conviction. Users who manually enter data every day are proving the tool solves something they care about - they're voting with their time. Watch which friction points people stick through and which ones kill retention. That's your real measurement.

One edge case I'd test: I update my bank balance today but leave an investment balance from six weeks ago. Does the dashboard make that mixed freshness obvious? Otherwise a newly dated total can look more current than it is.

For a quick review, I'd want each account's last-confirmed date, plus separate actions for 'checked, unchanged' and 'skip for now'. Skipping shouldn't silently mark an old balance as reviewed. This is an expectation from the description, not a bug I've verified in the app.

The privacy angle is underrated. There's a real segment of people who track net worth but won't touch bank sync with a 10-foot pole. Manual entry IS the feature for them — not the compromise. On first open UX: the biggest friction is usually the blank slate problem. If users don't see a structure that matches how they think about money (liquid vs illiquid, account types, etc.) they freeze. A guided first account entry or a simple example state helps a lot. Keep building — you're onto something real here.

Hey, this really resonates. I built something similar myself (bigger scope, budgets/investments/net worth), also fully manual, no bank sync.

On the weekly-update question: for me the thing that actually kept updates happening wasn't a reminder, it was making the "just update my numbers" path genuinely fast — like under 30 seconds if all you're doing is refreshing balances, completely separate from the "add a new account" flow. If updating feels like homework every time, it stops happening after week or two, no matter how good the notification is. Might be worth having two clearly different speeds: a quick balance-refresh mode, and a separate heavier flow for adding new stuff.

And yeah, agree with everyone else on manual vs sync: it's a real selling point for the people who actually care about it, not something to explain away.

The privacy angle is clear, but I’d test the first-session path against the “one number before one decision” idea. If I can enter a total and see a useful direction or goal view before choosing account types or currency details, that gives me a reason to continue. For the weekly habit, a catch-up flow that accepts one updated total after a gap may matter more than reminders. I’d be curious whether people who complete a second update are also the ones who reached a useful projection on first open.

I’d make first open a guided empty state, not a blank dashboard: let the user add one common asset with an example and show the resulting net-worth snapshot immediately. Sell manual as privacy and control, with a one-line explanation on the landing page and during onboarding of what it deliberately avoids—bank credentials and noisy sync—and who benefits. The biggest friction may be unclear scope, so show a sample portfolio and allow skip/confirm for items that have not changed rather than forcing every account edit. For retention, make each return produce a small insight or progress moment, such as change since last update, goal runway, or a stale-account cue, and let users set cadence per asset instead of relying on generic weekly reminders.

"Manual only" isn't a limitation you have to apologise for — it's the feature, if you frame it as one. I build offline-first mobile apps and the pattern I see is that people don't trust "no bank login" as an abstract privacy promise; they trust it when the app visibly needs less from them. So on first open, the question I'd ask isn't "what confuses you" but "how many decisions does the user have to make before the first number is on screen?" Currency, account type, goal, history — every one of those should default to something sane and be changeable later, not asked up front.

On weekly updating: the thing that kills manual trackers isn't effort, it's shame at the gap. If I skip three weeks, the app should treat that as normal (one entry, done) rather than as a hole to backfill. Good software removes decisions; a nag about missing weeks adds one.

One genuine question: what happens to the data if the user deletes the app — is there a plain export they own? For this kind of tool that's the trust signal that outweighs "no Plaid".

Got the same idea and built one last year and it's on Appstore (NO ad here, I won't mention it). People do really pay for it.

The core usage is not a high-frequency one, so trying find out relevant and high-frequency demands. Such as FX, holdings prices as they are changing every trading day.

Hey vlk, tried the app for a bit (web + app) — direct feedback:

1. First confusion: on your landing page, the subheading "Manual wealth tracking. No bank sync." feels visually cramped next to the overlapping phone mockups — not unreadable, just a bit crowded. Inside the app, onboarding (Accounts → Assets → Debts → Goal) is 4 screens in a row with no progress indicator, so you don't know how much is left.

2. Manual-only: for me it's a plus, not a dealbreaker. People who specifically look for this value not handing over bank credentials.

3. Weekly habit: what would actually bring me back isn't a reminder, it's something social — a group or feed where I can see other people saving too ("saving for a car", "saving for X") and feel like I'm not doing this alone. That drives way more engagement than a notification. Minor extra: the screen transitions are a hard white flash — a side swipe would feel smoother.

I'm still building up my Figma skills (I know how to design pages, just not every tool inside Figma yet), but if you're open to it I'd love to put together a quick concept mockup of the landing hero — happy to share it here.

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 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:

1. seed with 3 demo rows the user can edit instead of an empty table
2. adding an entry must take under 10 seconds, or weekly updates die
   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.

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.”