Ledgerly

Client: Ledgerly, bookkeeping software for freelancers. Team: two founders, both engineers. Engagement: three months, three days a week, 2025. Role: product design and front-end build.

The problem

The backend worked: bank connections, categorisation, tax calculations. The interface was a prototype the founders had built to test the backend, and it showed. Trial users connected a bank and then stopped. Nobody could say why, because nobody could get through the flow themselves without knowing where the buttons were.

What I did

Weeks one and two: watch people use it. Eight trial users, recorded, thinking aloud. Every one of them got stuck in the same two places: the transaction list, which showed everything at once, and the "file a return" step, which asked for things they had already given.

Weeks three to six: redesign the core flow in code. Connect a bank, categorise transactions, review, file. I built it in Svelte in the founders' repository from the first week, so there was never a mockup that had to be translated.

Weeks seven to twelve: the rest. Settings, billing, onboarding, empty states, errors. A twelve-component library with a written page on when to use each one.

What shipped

The version that is still live. The transaction list shows one week at a time with the uncategorised ones first. The filing step asks only for what the system does not already know, which turned out to be two questions.

What changed

Trial to paid conversion roughly doubled in the quarter after launch, by the founders' numbers. Support emails about "where do I" dropped to almost none.

"John designed in code from the first week. We never had a handoff problem because there was no handoff." Jonas Weber, Co-founder.

What I would do differently

Start the user sessions in week one, not week two. I spent the first week reading the codebase, which was useful, but the sessions told me more in a day than the code did in five.