Runway: A Private AI Financial Companion I Built for a Friend

Binayak — Sun, 04 Oct 2026 15:21:04 +0000

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 balance
No 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.

Solana Week 1, a beginner's perspective

Binayak — Sun, 26 Apr 2026 17:55:57 +0000

I just started with 100 days of Solana with MLH. The first week was about keypair identification. I have been a developer in the web2 domain for >5 years and finally thought of trying out web3.

If you’ve spent years building in Web2, “identity” probably means a combination of usernames, emails, passwords, and maybe OAuth providers. Users sign up, you store their credentials in a database, and your backend decides what they’re allowed to do.

On Solana, that entire model flips. There are no usernames. No passwords. No “Sign in with Google.”
Instead, identity is just a keypair — and once I understood that, everything else started to make sense.

When you generate an SSH keypair:

- You keep the private key on your machine
- You upload the public key to a server
- The server lets you in only if you can prove you hold the private key

No password needed. No central authority verifying you. Just cryptography.

Solana works almost exactly like this....

Your public key is your address on the network
Your private key proves that you own that address
Instead of one server, the entire Solana network verifies you

That’s your identity.

On Solana, your identity looks more like this:
....mFaf88c8tiVkKz3.....
That string is your public key, encoded in Base58 (a format designed to avoid confusing characters like 0, O, I, and l).

One shift that I found was the trade-offs:

Lose your private key → you lose access permanently
Leak your private key → someone else becomes you
No recovery system unless you build one on top

For a Web2 developer like myself, this feels extreme — because it is. But, you are replacing convenience with true ownership.

DEV Community: Binayak