flatmate

Tricount house management in AI era

Comment

Inspiration

So I came to the Netherlands as the international student almost 4 years ago and getting to student house was the real experience for me, I liked a lot of things about that, making new friends, studying and for sure drinking together. The only thing I didn't like is managing shared expenses. We always had these evening where we sit together and try to get the whole financial system from the rent payments, bills(especially considering that we use way different amount of heating during the winters), groceries shopping and other small stuff that for the first and second year students without stable jobs wasn't really small money(we were fighting for each cent). I took the Tricount by bunq as the reference point however I decided not to limit myself with the existing functionality and build the system from scratch that will satisfy all the user stories I have developed during the shared housing period. This was the "what" part, but the "how" part I think is way more important, I get really excited over the so called "AI-os" idea, personally I don't really enjoy clicking the interfaces on the small smartphone with my fingers and I personally believe that the most efficient way of interaction between human and computer systems are voice or at least human readable text(of course not considering BCI which I also work on (: ), so in this project I wanted to push this idea and reimagine the kind of Tricount type shared spending system with multimodal AI-native design.

What it does

This is a multi-user household-finance app where the AI is the interface, not a chat sidebar bolted onto one. Flatmates share one app: every receipt, request, split, and settlement happens between them, and the agent's job is to coordinate that, rather than answer questions about your account. You snap a receipt; the agent reads the line items, picks them up against the relevant house feed post, sees who already commented "I want the chips", and prefills the split for you to confirm. You say "settle the cleaning supplies with lena" and the agent doesn't just tell you the number, but it opens the exact pending RequestInquiry pre-filled with real data from system, ready to accept. The agent reads the screen you're on, mutates it in place when you ask him (tagging items on a receipt, filling a request form), and emits action cards into chat when the right move is opening another screen. Voice and text -> in, real money moving on bunq RequestInquiries and Payments -> out, sandbox flatmates settling actual pennies between them this is bank interface operated as a conversation.

Under the hood the agent has three modes of acting on the app: it can read your house's real state via mcp tools (splits, requests, balances, recent payments, posts, messages), it can propose an action card in chat that opens the existing page pre-filled with relevant data (a request, a split, "pay this specific debt", or "open the camera"), or it can patch the screen you're currently on (auto-assign receipt items, fill a request form). Every payment-side action goes through real bunq RequestInquiries and Payments on sandbox accounts — accepting a request actually moves money between four flatmate users, so the demo isn't a mock layer but a working multi-user financial app. Beyond split-the-bill, the app also has a house feed (text posts where flatmates can tag a receipt scan thread), per-split chats, balances per housemate, and one-tap "settle this specific request" rather than the all-or-nothing settle-up.

How we built it

We build it the same way every good product is built, I started with defining clear problem that I personally experienced in my life and built the user stories that I want to complete in order to consider the problem solved. After that researched what solution already exists, what they have good and what they missed, and created more structured design plan. Last year I started migrating from the SW more towards the team leader so I started to value more the planning rather then geeking the features ;P. I decided to try the new tool called Claude design that was released previous week to build the whole user experience and stories in the interface to see what the product will looks like, after that I exported the design to the Claude Code, planned the solution architecture and start building. Not sure if that is good or bad sign for you, but it is definitely good for me, during this building this product I haven't wrote a single line of code. The code quality is not perfect but it is really reasonable for the scope of the competitions with main modules covered with test, created with TDD. For the presentation I have also tried to use the new workflow with Claude Design and I am impressed and will definitely continue using it for presentations.

Challenges we ran into

The main challenge was that my team wasn't able to arrive so I was building alone so sometimes I felt really stuck in my context and also I was questioning the idea a lot, since there was not too much people to discuss and test it. Other then that the amount of work was really massive but I managed to make it fully work within the design scope, so that is fine.

Accomplishments that we're proud of

The Product, I am really impressed with the User Experience and I will definitely apply the same concepts in my other applications. I managed to fully recreate the idea of native AI integration into interface as I envisioned it, and it turned out to work even better then I expected. I felt goos bumps when I've seen the tools used and interface interaction for the first time at 4:00 todday.

What we learned

I'd say not really too much, this is not about learning this is about practice, about shaping ideas, understanding the buisness value, about designing proper scope and creating the tasks that eventually make the project work. The distinct point I learned here is new pipeline for creating the presentation part using Claude Design.

What's next for flatmate

Hm, I'd say to show it to the Tricount team with all the code that will be available on the GitHub. If you ask me as the product owner of this solution, I would tell integrating this as service and promoting as the solution for the students and expats is valuable. Since every user that decides to give a try to this service automatically brings 2-5 more users into this system due to the selected focus group and then considering the fact that bunq killer feature among banks is the ease with which you create account in the ecosystem give us high probability to get the new users into our system, which directly converts to income. The one more argument why this solution for this target group make sense is the fact that majority of shared households are actually student houses with international students which don't yet have a card. And if the first thing they see when they go to the new country is the new flatmate telling them to make the bunq account to live with them, then the chance that they select our bunq is quite high. That's what I think for flatmates future

Built With

Share this project:

Updates