When banks freeze your parents’ assets.

The problem

The app’s ultimate purpose is generating yearly trust reports that a government branch can request at any time, and that for any year. But not all of our customers are necessarily regular users. Their asset values get recorded when they start using the app but don’t always get updated over time. Updating an asset value should be trivial but it invalidates any past report our customers would try to generate.

What we rejected

The obvious approach would be to "instance" every fiscal year: close the books, copy all data into the next term, and work from that snapshot going forward. Freee, a popular Japanese accounting service, works this way and I think it’s a great approach. But family trusts aren’t companies. And our users are not accountants or financial professionals. Plus, they don’t even have to file reports every year; they just need to be ready if asked. Forcing customers to formally close each year felt too rigid. I wanted to let them manage (or not) their assets with flexibility.

The insight

I realized the scope of the problem was narrower than it seemed. Bank transactions already had a natural timeline through journal entries, since every expense and income is dated. Only assets were the problem. A building’s assessed value, a stock portfolio’s balance: these change independently of any transaction. So I scoped the solution to assets only.

What we built instead

A "revisions" system. Think of it as a timeline for mutable assets information. On any asset page, customers can add a revision, a snapshot of that asset’s value at a point in time. When generating a yearly report, the system silently pulls the correct historical values and prompts the customer to double-check. If something looks off, they can jump straight to the asset page and add a revision right from the report flow.

The payoff

For most users, I believe this system is invisible. They never have to think about managing "instances" or closing fiscal years, which makes the app drastically simpler than traditional accounting software. At the same time, our more advanced users, who frequently update their assets information, appreciate how easy it is to generate reports with a few clicks.

The problem

Shortly after our initial launch, we added the option to connect bank accounts through a well-known API so customers could automate transaction tracking instead of entering everything manually. But this service connects banks from all over Japan, and those connections are... fragile, to say the least. They can fail without warning and not every update is real-time. Sometimes it takes half a day to get fresh data. And if a user disconnects their bank from the API service on their own, we lose the connection on our end too.

What we rejected

The easy approach would have been to treat the bank connection as binary: it works or it doesn’t, and when it doesn’t, show an error page. But I think that would have left our customers stranded with no visibility into what went wrong and no help towards the resolution. We also needed granularity in error handling as we had cases where one bank would fail while another worked perfectly.

The insight

We realized that connection problems would not be exceptions. On the contrary, they could be, to some users, a relatively standard experience. If we designed for that reality instead of treating it as an edge case, the experience could stay smooth even when the infrastructure wasn’t cooperating. We first decided to map out the many different states of the bank connection and design for each one.

What we built instead

Every surface that touches bank data has embedded alert states: the dashboard, the wallet list, individual account pages. Using color, messaging, iconography, and dedicated banners, we communicate clearly what went wrong and how to fix it. Journals created from imported transactions survive disconnections so nothing gets lost. We always offer an explanation and whenever possible, a clear path to resolution.

The payoff

The system degrades gracefully instead of breaking silently. Our customers always know what’s going on with their bank connection and what to do when something goes wrong. It was important for me to ensure that a part of the frustration that comes from dealing with a third-party API was absorbed by the design and not passed on to the user.