Tohobil: A Fund Manager Where Every Taka Is Traceable
Our friends’ savings fund outgrew a Google Sheet and Messenger. I spent a 5-day break building an open-source, Bengali-first app to replace them.
The One-Line Summary
Our friends’ savings fund was running on a Google Sheet and Messenger, so I spent a five-day break building tohobil: an open-source, Bengali-first fund manager where nothing is ever deleted.
Project Metadata
My role: Product owner, designer and builder. I wrote the spec, designed the rules and tested it; Claude Code wrote most of the code.
Timeline: 2 days of planning, then built over a 5-day break in October 2026
Status: Built and in testing. We plan to start using it at the beginning of 2027.
Scale: One group of about 8 members holding 20 shares. Built for up to 50 members.
Stack: TypeScript, Fastify, PostgreSQL, React, Tailwind CSS. PWA and Android app. Self-hosted.
Why This Existed
We’re a group of friends. We know each other and we trust each other. On purpose, we didn’t add anyone who might lose motivation after the first few months.
Each share pays a fixed amount every month. The fund invests that money, and we decide together what to do with it.
I’m the cashier. Until now, everything ran on a Google Sheet plus Messenger and WhatsApp groups. When someone sent money, they knocked me on Messenger. I checked, confirmed, and ticked their box in the sheet.
The Problem Wasn’t a Fight. It Was Growth.
Nothing went badly wrong. With so few members, there isn’t much drama. The problem is what happens as it grows.
The sheet now has a lot of checkboxes and status changes. Every member has a box with multiple fields. Then we started talking about adding new members, and I couldn’t see how I’d manage it.
The cracks were already there:
Sometimes I’m busy, someone sends money, and I can’t reply.
Meeting fines are hard to enforce.
Some members can’t always pay the exact amount.
The rules aren’t written in one place.
To find out how much someone has paid, you need to open several links.
It was a hassle for everyone, not just me.
What “Trust” Means Here
When I asked myself what a member actually needs to see, the answer was simple. They want to know their money is safe, how much they’ve put in, and that their payment was marked. And when they paid, with no confusion about it.
Every design decision came back to that.
Key Decisions
Decision 1: Nothing is ever deleted.
As a cashier, building trust matters more than anything. I kept asking myself: what if, five years from now, someone asks for the account of one particular day? How would I answer? How would I show the log?
So no financial record can be edited or deleted. A mistake is fixed with a reversal entry, and the database itself refuses anything else. Every taka has a who, when, how much, how and proof.
Decision 2: Every spend needs a vote.
So nobody is unhappy, and nobody can say, “You did this without asking me.” Votes are public and can be changed until the vote closes.
Decision 3: Members on phones, the cashier on a desktop.
Most of our members are probashi, working abroad. They put their energy into the fund, not into learning software. So the member side is phone-first and simple, while the cashier side gets the full desktop view.
Decision 4: Bengali first.
So members who don’t follow most of the English can easily understand what to do. Every label is in Bengali, money is grouped as lakh and crore, and Bengali digits are a setting.
Decision 5: The asset page follows our own rules.
This was the hardest page. We have to make many decisions here: what kind of investment, whether it’s one transaction or rolling payments over time. I designed the page around the rules we already follow in our fund’s constitution, so t¡he app behaves the way we agreed to.
How I Built It
I planned for two days. When the plan was ready, I went straight to design and build.
I didn’t start in Figma. This was a side project and an experiment. If I’d spent days in Figma, I knew my building energy wouldn’t last, and I’d probably lose the wish to build it halfway. So I built it while the dopamine lasted. I had a five-day break from the office and spent 14 to 16 hours a day on it.
I wrote everything into one long spec: the rules, the roles, the money logic, the stack and the build phases. Then I handed that spec to Claude Code to build, phase by phase.
A Funny Detour
Before that, I tried an experiment. I’d got a free million tokens on one of Qwen’s top models. I asked it a few questions and it answered fine. Then I asked if it had a CLI. It said yes, and told me to download Claude’s CLI.
I was confused. I’m chatting with Qwen, and it’s recommending Claude? So I asked who it was. It said, “I’m Claude, made by Anthropic.” I laughed.
Still, free credits are free credits. I gave it the full spec. It returned every file as text in the chat, and couldn’t give me a download. So I downloaded each one by hand and named it myself. Then I asked it for the folder structure, and had Copilot arrange the files to match.
Then I gave the whole folder to Claude and asked for an audit. It took 35 minutes and found hundreds of bugs and broken pieces. That was a fun way to see what a model is really capable of underneath.
Testing It Myself
The repo has a test guide. I asked Claude to give me the test cases one by one. I ran each one myself and ticked it off. When something failed, I listed it and sent it back to be fixed. I’m not finished yet.
As a designer, this was the fun part and the boring part at the same time.
The repo checks a few things automatically too. Colour contrast meets WCAG AA in light and dark mode. Every member screen passes an accessibility check. With 100,000 ledger rows, every main screen answers in under 40 ms.
Where It Is Now
We’re not using it with real money yet. This is the end of our fund’s year, so the plan is to start fresh in 2027. A new year, a new start, a new vibe.
I shared a few screenshots in the group. People loved them, in reactions. The non-tech members didn’t reply at all, and that’s something I need to think about.
Next: finish testing, make a proper release, then think about the future. I’ve named it tohobil, not after our own fund, so it’s open source and another group with the same need can use it too.
What I Learned
How a whole product ecosystem works. Until now I’d mostly seen that side as a designer, and vibe-coded single-page features. This was a full project from start to finish, with tests.
Trust is a design problem. Most of the design wasn’t screens. It was rules: what can’t be changed, who decides, who sees what.
Build while the energy is there. For a side project, momentum matters more than a perfect Figma file.
I’m still a little afraid. Is this overkill for 8 members? Will it be hard to manage? Will people find lots of bugs once they use it? Hopefully it turns out easier than I fear.