The Problem with Traditional Expense Splitters
If you've ever used group expense splitting tools, you know the drill: great concept, but many implementations leave something to be desired. A common pain point is when timelines mix expenses from different groups, making it difficult to focus on a specific trip or event. Want to quickly review just your weekend getaway expenses? You might find yourself scrolling through unrelated bills and dinner splits from other groups.
This counter-intuitive design pattern got me thinking: there has to be a better way.
A Graph-Based Mental Model
The breakthrough came when I realized expense splitting is fundamentally a graph problem. Here's the elegant simplicity:
- Nodes represent people in your group
- Directed edges represent money owed (A → B means A owes B)
- Edge weights are the amounts
When you add an expense, you're essentially creating edges in this graph. If Alice pays $120 for lunch shared equally among three people, she's owed $40 by Bob and $40 by Charlie. That's two edges: Bob → Alice ($40) and Charlie → Alice ($40).
This mental model is intuitive because it mirrors how we naturally think about debts: "I owe Alice $40" is a directed relationship with a value attached.
Building expense-splitter
Armed with this insight, I built expense-splitter as a graph-based tool. Key design decisions:
- Group isolation: Each group is its own separate graph. Your Napa trip expenses never mix with your apartment utilities.
- Flexible splitting: Support for equal splits, weighted splits, and percentage-based splits—all translating cleanly to edge calculations.
- Clean settlements: The graph makes it trivial to calculate who owes whom. No more confusing chains of "Alice pays Bob who pays Charlie"—just direct settlements.
The MCP Integration: Where It Gets Interesting
Here's where modern AI tooling transforms the experience. I packaged expense-splitter as an MCP (Model Context Protocol) tool and built an agent using Google's Agent Development Kit (ADK) in Go.
The result? A conversational interface that's actually intuitive:
User: let's do expense splitting
Agent: I can help with that! First, let's create a group.
What would you like to name it?
User: create a group called napa-trip
Agent: Great! I've created a group called 'napa-trip'.
Now, who are the members of this group?
User: add alice, bob, charlie to the group
Agent: I've added Alice, Bob, and Charlie to the napa-trip group.
Now, let's add some expenses...
No clicking through forms. No dropdown menus. Just natural conversation.
Adding Expenses Naturally
The real magic shows when adding expenses:
User: add an expense by alice for lunch. 120$
Agent: I've added a $120 expense for lunch, paid by Alice.
What's the next expense?
User: it's for snacks and drinks by charlie. 60$
Agent: Got it. $60 for snacks and drinks, paid by Charlie, has been added.
Even complex splits feel natural:
User: add an expense by bob for show tickets with unequal weights
Agent: Okay, Bob paid for show tickets with unequal weights.
What was the total amount? And how would you like to split
the weights among Alice, Bob, and Charlie?
User: 100
Agent: And what are the unequal weights for Alice, Bob, and Charlie?
User: alice: 1, bob:2, charlie:1
Agent: I've added the $100 expense for show tickets, paid by Bob,
with the following weights: Alice 1, Bob 2, Charlie 1.
Bob paid $100 but his share (weight 2 out of 4 total) was $50, so he's actually only owed $50.
The Payoff: Clear Settlements
When you're ready to settle up:
User: get group details now
Agent: Here are the details for the 'napa-trip' group:
**Members:** Alice, Bob, Charlie
**Settlement Details:**
- Bob needs to pay Alice $15
- Charlie needs to pay Alice $20
- Charlie needs to pay Bob $5
Visualizing the Graph: DOT Notation
One of the advantages of modeling expenses as a graph is that you can actually see the structure. The tool exports the graph in DOT notation, which can be visualized using Graphviz:
digraph "napa-trip" {
"alice" [label="alice"];
"bob" [label="bob"];
"charlie" [label="charlie"];
"alice" -> "bob" [label="$25.00"];
"alice" -> "charlie" [label="$20.00"];
"bob" -> "alice" [label="$40.00"];
"bob" -> "charlie" [label="$20.00"];
"charlie" -> "alice" [label="$40.00"];
"charlie" -> "bob" [label="$25.00"];
}
This represents the complete debt graph showing every individual obligation. Notice that this is the raw graph showing all pairwise debts from each expense. The settlement algorithm then simplifies this:
- Alice owes Bob $25 but Bob owes Alice $40 → Net: Bob owes Alice $15
- Charlie owes Alice $40 but Alice owes Charlie $20 → Net: Charlie owes Alice $20
- Charlie owes Bob $25 but Bob owes Charlie $20 → Net: Charlie owes Bob $5
The beauty of the graph representation is its transparency. You can:
- Visualize it: Paste into any Graphviz tool to see the network of obligations
- Debug it: See exactly how each expense contributed to the final settlements
- Audit it: Verify the math by tracing through the edges
- Understand it: The visual representation makes the settlement logic obvious
This level of transparency is rare in expense splitting tools. Most are black boxes where you input expenses and get settlements without seeing the underlying logic. By exposing the graph, users who want to understand why they owe a certain amount can trace it back through the structure. Clean, minimal, and derived directly from the graph structure. No intermediate transfers, no confusion.
Why This Matters
The combination of a sound data model (graphs) and an intuitive interface (conversational AI) creates something genuinely better than existing solutions:
- Cognitive alignment: The graph model matches how we think about debts
- Context preservation: Groups stay separate, making it easy to review specific events
- Conversational ease: No UI to learn, just describe what you want
- Extensibility: MCP tools can be integrated with various AI platforms (Claude Code, custom agents, etc.)
Technical Architecture
For those interested, the stack is:
Core logic: Graph-based settlement calculation implemented in Go
MCP layer: Exposed as Model Context Protocol tool implemented in Go
Agent: Built with Google's Agent Development Kit - ADK in Go
Interface: Natural language via LLM
The MCP abstraction means the same tool can be used from CLI tools like Claude Code, web interfaces, or custom agents—wherever you can connect an LLM.
Conclusion
Sometimes the best solutions come from stepping back and asking: "What's the fundamental structure of this problem?" For expense splitting, it was recognizing the graph nature of debts and obligations.
Combined with modern AI tooling, we can finally build interfaces that feel as natural as asking a friend, "Hey, what do I owe you?"
The code is a testament to how good abstractions—both in data modeling and tool interfaces—can transform user experience from frustrating to delightful.
Have you experienced similar frustrations with existing tools? I'd love to hear about problems you've solved by rethinking the fundamental data model.
Top comments (1)
Insightful
Some comments may only be visible to logged-in visitors. Sign in to view all comments.