The hardest part of building a financial app is knowing when not to show a number

This morning, while testing the latest version of zFinia on a physical device, I found something that looked ridiculous.

The app had an income entry sitting right there:

Wage — $5,555 — Due today.

But another part of the app was telling me:

Your next regular income is still needed.

Same data. Same app. Two completely different interpretations.

It was a bug.

And although bugs are frustrating, this one was a pretty useful reminder of one of the principles that has increasingly shaped how we’re building zFinia:

In personal finance, being confidently wrong is much worse than admitting you don’t know.

A number isn’t automatically useful

There is a natural temptation when building financial software to always give the user an answer.

People open a finance app because they want clarity.

How much money do I have?

What’s coming up?

Can I afford this?

Am I doing okay?

The obvious response as a product builder is to calculate something and put a nice big number on the screen.

But that creates another problem.

What if the information underneath that number isn’t complete?

Imagine you have $2,000 sitting in your everyday account.

That’s a fact.

But it doesn’t necessarily tell us what you can safely spend.

We might not yet know when your next income arrives, which bills are due before then, whether all of those bills have actually been recorded, whether a credit card or loan repayment is approaching, or whether the balance we’ve been given is still current.

If we ignore those unknowns, we can make the app look very clever.

We can also make it dangerously misleading.

So we’ve been working toward a different rule:

Show the position we know before trying to tell someone what it means.

And when something important is unknown, say so.

That changed how we thought about onboarding

For months, we’ve been working through how much information zFinia should ask for when somebody first opens it.

The initial instinct is fairly obvious.

If we want to understand someone’s financial position, ask them for everything.

• Accounts.
• Income.
• Bills.
• Debts.
• Repayments.
• Goals.
• Emergency funds.
• Other commitments.

The more information we collect, the more useful the product should become.

Technically, that makes sense.

Behaviourally, I’m no longer convinced it does.

We’re trying to build something that reduces financial mental load.

Making somebody complete a 20-minute financial interrogation before they’re even allowed to see the product risks creating the exact thing we’re trying to remove.

So we changed the architecture.

The first experience is now deliberately small.

Give zFinia a truthful starting position — essentially, where the user’s everyday money sits today — and let them reach Home.

That’s enough to begin forming a picture.

It is not necessarily enough to produce every financial conclusion.

That distinction matters.

Getting into the app isn’t the same as earning an answer

Once somebody reaches Home, they can choose to build out the rest of their financial picture.

• Income.
• Bills and recurring commitments.
• Liabilities.
• Goals.
• Other useful context.

They can do it in one sitting, or leave halfway through and come back later.

They can skip an area.

They can refine things through normal use.

But there is something we’re deliberately keeping separate:

Finishing onboarding does not automatically make the financial position trustworthy.

That’s an easy distinction to lose in software.

A lot of onboarding systems effectively work like this:

Step completed = information complete.

But those aren’t the same thing.

Someone can review their bills and still have forgotten one.

They can skip liabilities because they don’t have the information handy.

They can finish an income section while the underlying information has become stale.

The workflow can be complete while the financial evidence is not.

So zFinia needs to understand both.

What has the person reviewed?

And separately:

What do we actually know?

Unknown has to remain unknown

This sounds like a small product detail, but I think it matters enormously.

If someone hasn’t entered a bill, the answer isn’t necessarily:

$0.

It might be:

Unknown.

If somebody skips the liabilities section, that doesn’t prove they have no debt.

If an income schedule hasn’t been confirmed, that doesn’t mean no income exists.

And if the information isn’t strong enough to calculate something responsibly, the app shouldn’t quietly fill the gaps with assumptions simply because a completed dashboard looks better.

That does mean zFinia will sometimes be less impressive.

There will be moments where another product might confidently display a number and we display:

We don’t know yet. Here’s what’s missing.

I’m becoming increasingly comfortable with that trade-off.

Trust is more valuable than theatre.

Which brings me back to this morning

The bug I found was actually quite subtle.

The income was scheduled for today’s date.

One part of the app correctly understood that as Due today.

Another part was comparing that date against the exact current time.

So once midnight had passed, today’s income could technically look like it was already in the past.

At 10am, the software could simultaneously believe:

This payment is due today.

and:

There is no upcoming income.

Obviously wrong.

But there was one part of the behaviour I was actually pleased to see.

The app did not respond to that contradiction by making up a Safe-to-Spend number.

It withheld the answer.

The bug still had to be fixed — and it has been — because contradictory information destroys trust as well.

But I would rather discover a system refusing to make a financial claim than discover one quietly making the wrong claim look authoritative.

That distinction is becoming fundamental to how we’re building zFinia.

Restraint is becoming part of the product

One of the things I’m learning while building zFinia is that financial software doesn’t necessarily become better by saying more.

Sometimes it becomes better by knowing when to stop.

• Don’t make somebody enter information before it becomes useful.
• Don’t turn missing information into zero.
• Don’t turn workflow completion into financial certainty.
• Don’t give advice before establishing position.
• Don’t show a precise number simply because the interface has somewhere to put one.

We’re getting close to putting this thinking in front of real beta users.

That matters because, at this stage, part of this is still a product hypothesis.

In the conversations and research we’ve done so far, one theme keeps appearing in different forms: people carry a surprising amount of financial information around mentally, in spreadsheets, in banking apps and in routines they’ve built for themselves.

The systems differ.

The cognitive load often doesn’t.

What we haven’t proved yet is whether our approach genuinely reduces that load.

That’s what the beta needs to tell us.

And increasingly, I think the most interesting question isn’t:

Can people complete the setup?

It’s:

Does the product earn enough trust that they stop feeling the need to constantly check everything themselves?

If we can get that right, the number on the screen becomes almost secondary.

Because the real product isn’t the number.

It’s the confidence that the number deserves to be there.