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. But asset values change over time. If you generate a report in 2024 for the year 2022, you'd pull current values, not what they were worth two years ago. The numbers would be wrong.

What we rejected

The obvious approach was 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. But family trusts aren't companies. They don't have to file reports every year; they just need to be ready if asked. Forcing customers to formally close each year felt too rigid.

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. 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, this is invisible. They never have to think about managing "instances" or closing fiscal years, which makes the app drastically simpler than traditional accounting software. For the minority, frequently changing assets, the revision system clicks right after using it for the first time.

The problem

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. They can fail without warning. Not all updates are 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 that would leave customers stranded with no visibility into what went wrong, no path back, and potentially missing financial data.

The insight

Connection problems aren't exceptions. They're a normal state of the system. 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. Nothing gets lost. Reconnection is always available.

We also built a batch processing UI for incoming transactions. When data arrives from the API, it doesn't become a journal entry automatically. Customers categorize each transaction first: grocery shopping, care facility payment, utility bill. And when a manual bank account gets upgraded to an API-connected one, a short quiz walks through the transition: where to start importing from, how to reconcile existing data.

The payoff

The system degrades gracefully instead of breaking silently. Customers always know what's going on with their bank connection and always have a way back. The complexity of dealing with a third-party API is absorbed by the design, not passed on to the user.