Reworking CashBook's web architecture, and an 8x jump in sessions

The job

I joined CashBook when the team was still growing along with the product — seven engineers: five on mobile, two on backend infra, and one CTO. I joined for my mobile experience, but since I’d worked on web applications before, I was asked to take over the web app instead.

Web was behind. It had nowhere near feature parity with mobile, which is exactly why it had far fewer users, nobody was choosing to work from a browser when the app could do more. The first thing we did was start bringing mobile features over to web, so people could actually use it from their desktop.

What CashBook actually does

CashBook is a UPI and card wallet system built for small and medium businesses. The core problem: businesses disburse money regularly for day-to-day expenses, what’s usually called petty cash, and once you’re past a certain size that gets genuinely hard to track. CashBook exists to make that disbursement and the bookkeeping around it manageable.

For the fintech pieces, we built on third-party infrastructure rather than our own: LivQuik for digital cards, M2P for UPI.

Closing the gap

I shipped the transaction-history feature for the Payments module on web, and integrated LivQuik’s card system so users could see transaction history and card details without leaving the browser. Between the two, web finally had a reason to exist next to the mobile app.

Auth got a rework too. We were verifying users over OTP, on SMS and WhatsApp, and the cost of sending those at our volume had gotten real. I built out social auth (Google, Phone, Email) alongside the CTO specifically to cut that cost down, not for the UX story, though that came free with it.

The pivot: from books to businesses

Here’s the part I actually want to be clear about: the old architecture wasn’t broken. It was good, and I built on top of it rather than replacing it.

CashBook started as book-keeping for individuals and small businesses, structured as Books → Book → Transactions, with settings and permissions hanging off that. Then we saw a real spike in business usage, and the product pivoted to treat businesses as the central thing, not books. So the structure became Businesses → Books → Book, with a business layer added on top of what was already there.

That new layer was built with scaling in mind from the start, which mattered later: once we added payments to the mobile app, bringing the equivalent visualization to web was straightforward, because the layer underneath was already shaped to carry it. Permissions got more accurate along the way too, since a business-first structure needs business-level permissions, not book-level ones.

The codebase itself was an Nx monorepo: one apps directory holding the actual product, and a set of shared libraries we’d built up over time for business logic, the component layer, the design system, and other utilities, kept deliberately separate. That separation-of-concerns principle was already in place before me. I extended it, I didn’t invent it.

Building it

The business layer and the payments layer on top of it took nine months, across both web and mobile in parallel. No major pushback along the way, the team was small, technical, and genuinely easy to build with, so this part of the story is a smooth one, not a fight.

Where it got hard

The friction wasn’t the architecture. It was the design system.

Design brought in a new system partway through, and I had to wire it into the product: design tokens, and dark/light mode support, built with vanilla-extract. I got stuck more than once figuring out how tokens should actually flow through the theming setup. It took a couple of days of real research to get it right, not a quick fix.

The payoff

Web sessions went up 8x. That number is tracked through the analytics events we had spread across both web and mobile, so it’s not a guess, it’s what the dashboards showed. The honest story behind it: closing the feature-parity gap is what drove it. Once web could do what mobile could do, payments, transaction history, card details, people actually started using it.

What I’d do differently

Read and understand more before implementing, everywhere, not just here. That’s become more true, not less, now that AI makes it easy to start producing code before you’ve actually understood what you’re producing it into.