This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
I built Runway, a personal financial companion for a friend who freelances and has an irregular monthly income.
Their problem is simple but surprisingly difficult to answer consistently:
“Can I afford this right now without messing up the rest of my month?”
Traditional budgeting tools are good at showing what already happened. They can tell you how much you spent last month, what your largest categories were, and what your current balance is.
They don't do a particularly good job of helping with the decision that comes next.
For example:
“I just received ₹50,000. Can I spend ₹15,000 on a trip next weekend?”
Runway is designed around answering that question. The user provides their transaction history, income patterns and a few personal preferences such as their minimum safety buffer. Runway then combines historical data, forecasting and an AI agent to reason about future scenarios.
"Financial runway" is the number of months a business or individual can survive before depleting all cash reserves at a constant net burn rate
Instead of simply replying with a generic budgeting recommendation, it can:
- analyse the user's historical transactions
- forecast expected cash flow
- account for recurring expenses
- remember personal preferences such as a minimum cash buffer
- model a proposed expense as a scenario
- explain the result conversationally
- use live web information when a decision depends on current prices or alternatives
The goal isn't to tell someone how they should spend their money.
It is to help them understand the consequences of a decision before they make it.
Structure
User
│
Chat / Voice
│
▼
Gemma Agent
│
Mastra Agent
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
TabPFN MongoDB Atlas SerpApi
forecastin memory/data live search
│ │ │
└────────────┼────────────┘
│
▼
Response
│
ElevenLabs
(voice)
How I Built It
One of the main design decisions was to not make the LLM responsible for everything.
Runway separates language reasoning, prediction, memory and external information into different components.
Gemma
Gemma is the language model at the centre of the application. It is responsible for understanding the user's question, deciding which tools are relevant, interpreting their outputs and communicating the result.
For example, when the user asks:
“Can I afford ₹15,000 this weekend?”
Gemma does not try to mentally forecast the user's finances from a CSV. Instead, it can decide:
I need:
→ recent financial data
→ recurring expenses
→ a cash-flow forecast
→ a scenario with an additional ₹15,000 expense
It then calls the relevant tools and uses those results to produce the final answer. This distinction is:
The LLM does the reasoning. The prediction model does the prediction.
TabPFN
TabPFN is used for the numerical side of the problem.
The transaction history is transformed into structured features that can be used for forecasting.
Conceptually, the data looks like:
date
income
expense
category
balance
day_of_week
recurring_flag
Runway uses that historical information to estimate future cash flow.
The agent can then compare scenarios such as:
Projected balanceNo additional spend ₹31,800
₹12,000 trip ₹19,800
₹20,000 purchase ₹11,800
Mastra
Mastra acts as the agent's orchestration layer. Instead of a single prompt with a huge amount of logic embedded inside it, Runway exposes individual capabilities as tools:
- forecast_cashflow()
- get_account_summary()
- get_recurring_expenses()
- create_scenario()
- search_current_price()
MongoDB Atlas
MongoDB Atlas is used as the application's data layer. It stores the information Runway needs to maintain context between interactions. This is particularly useful for preferences that shouldn't have to be repeated every time.
ElevenLabs
I added a voice interface because financial questions are often more natural to ask than type. Instead of opening a budgeting application and filling in forms, a user can simply ask:
“I got paid today. Can I afford a ₹10,000 purchase?”
The voice layer handles the conversational part while the underlying Runway agent still performs the same structured workflow.
This also made the demo more representative of how I would want a friend to actually use the product.
SerpApi
Some financial decisions depend on information that isn't in the user's transaction history.
For example:
“My current broadband plan costs ₹999. Are there cheaper options?”
or:
“I'm thinking about buying this phone. What are the current prices?”
For these cases, Runway can use live web search rather than relying solely on information contained in the model.
Sentry Agent Tracing
One of the things I wanted to avoid was building an agent that appears intelligent without knowing what it is actually doing. Sentry tracing lets me inspect the agent's execution.
Example:
User question
│
├── Retrieve financial context
├── Retrieve user preferences
├── Run TabPFN forecast
├── Create spending scenario
└── Generate final response
This makes latency, failures and individual tool calls visible.
Why Does Open Innovation Matter?
The most important reason I chose an open approach is control.
Financial data is unusually personal. A transaction history can reveal where someone shops, where they travel, how frequently they get paid and what they spend their money on.
Using an open-weight model gives me a different architecture. The core AI system can be run in an environment that I control, while the application itself remains modular.
Privacy
A user's financial history can remain within infrastructure controlled by the application rather than automatically becoming context sent to a proprietary model for every request.
Separation of responsibilities
Open components also made it easier to build the system as separate pieces.
Prize Categories
- Best Use of Gemma
- Best Use of TabPFN
- Best Use of Mastra
- Best Use of MongoDB Atlas
- Best Use of ElevenLabs
- Best Use of Sentry Agent Tracing
- Best Use of SerpApi
- Best Use of Temporal
Top comments (0)