Health and fitness apps have spent years solving a hard problem: how do you make something as dry as tracking your activity genuinely engaging? Whoop, Apple Fitness and Strava all landed on a similar answer - give people a score. A single number that reflects how well they’re doing, updates in real time and creates a feedback loop they actually care about.
The same problem exists in personal finance, and nobody has really cracked it. Most budgeting apps show you data. They leave the interpretation to you. Elaira is an attempt to apply the health and fitness model to your financial life - because keeping track of your financial health matters just as much as your physical health, and it deserves the same quality of tooling.
The core idea is simple: instead of confronting you with raw numbers and spreadsheets, it gives you a score - a single number that reflects how well you’re managing your money in a given cycle. Stay above 70 and you’re doing well. Drop below it and you know something needs to change.
Here’s a walkthrough of the prototype as it stands.
Home
The home screen surfaces the two scores front and centre alongside your total balance and connected accounts.
In this example, spending is a healthy 93 while saving is at 34 - more on that in a moment. Below the scores there’s a daily summary section (still loading here) and a horizontally scrollable row of account cards. Recent transactions sit at the bottom.
The intention is that you can open the app, take in the two numbers and immediately know where you stand. No digging required.
Each score is calculated independently. The spending score measures how well your actual spend tracks against your available budget at the current point in the cycle - if you’re spending faster than the cycle allows for, the score reflects that immediately. The saving score measures progress against your monthly savings target, weighted by how far through the month you are.
// Spending score
budget = income - savings_target
pace = (spent ÷ budget) ÷ (elapsed_days ÷ cycle_days)
score = clamp(100 × (2 - pace), 0, 100)
// Saving score
rate = saved_this_month ÷ monthly_target
weight = e^(−λ × days_elapsed)
score = clamp(100 × rate × weight, 0, 100)The λ (lambda) in the saving score is the decay constant - it controls how quickly the influence of past behaviour fades. A higher λ means the score responds more aggressively to recent activity, which is what gives the rolling model its Whoop-like quality.
Scores - Spending
Tapping into the spending score gives you the detail behind the number.
A 93 here means spending well within budget across all categories. The app surfaces a short line of context - keep it up and you’ll stay comfortably above the 70-point target - and a chart showing cumulative spend across the current cycle. At 7 days in, £2,076.78 has been spent since 25 March.
Scores - Saving
The saving score tells a different story.
A 34 is below the 70-point target, shown in red. The reason: no savings transfers have been logged yet this month against a £500 target. The chart below shows savings history month by month - there was a strong peak in March, but April is starting at zero.
This contrast is intentional. Having two separate scores means you can be doing well in one dimension and poorly in another, which is often the reality. The app doesn’t let a good spending score mask a savings problem.
Transactions
The transactions screen is a straightforward chronological feed pulled from your connected accounts.
Merchant icons are pulled in automatically. You can see the usual mix here - coffee, groceries, subscriptions, rent and a £250 transfer to Marcus by Goldman Sachs (which Elaira would count as a savings event). A calendar button in the top right lets you jump to a specific date.
Settings
Settings shows your profile, connected accounts, financial inputs and score model configuration.
The key inputs are monthly net income (£2,500 here) and a savings target (£500/mo). These feed directly into how the scores are calculated.
The score model field is interesting - it’s currently set to Rolling (Whoop-style), borrowed directly from how Whoop calculates recovery. Recent behaviour matters more than older events and scores fade over time rather than resetting hard at the end of a cycle. A single bad week shouldn’t permanently tank your score, but you can’t coast on a good month either. That dynamic tension is what makes fitness scores motivating, and I think it translates well here.
The Stack
The prototype is built in React Native. My familiarity with React made it a natural starting point, and it gives the option to expand from iOS to Android quickly without maintaining two separate codebases. In an ideal world the iOS app would be built in Swift, and that’s not off the table further down the line. Dart and Flutter were briefly considered, but React Native has proven easy to work with and straightforward to migrate from if it comes to that.
On the backend, I’ve started building out the real API in Go. TypeScript with Node or Bun with Next.js were the obvious alternatives - and the case for fullstack JavaScript isn’t lost on me, particularly when it comes to onboarding other developers. But I’ve never been a fan of fullstack JS and didn’t want to build Elaira that way. Zig crossed my mind but I couldn’t justify the benefits of manual memory management for this kind of project - I’m still looking for the right thing to build in Zig. I’ve also been wanting to find a project for Gleam, though that still hasn’t happened yet. Go ended up being the right fit: I have solid experience with it and it hits a good middle ground between performance and speed of development.
On the data side, we’ve been experimenting with TrueLayer as the Open Banking layer. The prototype currently reads Monzo statements, but TrueLayer gives us a single API across a much broader range of banks and financial institutions - which is essential if Elaira is going to be useful to more than just Monzo users. Getting that integration right in the Go API is one of the first things on the list.
Security and Performance
Building a financial application carries a different weight to most software projects. Users are handing over access to their bank accounts and trusting you with some of the most sensitive data they have. That’s not something to take lightly, and it shapes every decision from the ground up.
Security is the primary concern. Open Banking via TrueLayer helps here - we’re not storing credentials or handling raw bank access ourselves, and TrueLayer is a regulated entity with its own compliance obligations. But that only goes so far. How we store tokens, how we authenticate users, how we handle and encrypt data at rest - all of that needs to be right before Elaira goes anywhere near production. This is an area where cutting corners isn’t an option.
Performance matters too, and for a slightly different reason. With financial data, a slow or unresponsive app doesn’t just frustrate users - it erodes trust. If the scores take a moment to load or a transaction feed lags, it starts to feel unreliable in a context where reliability is everything. Go is a good fit for this partly because of how it handles concurrency, which becomes relevant as soon as you’re making multiple upstream calls to banks and processing transaction data in real time.
These aren’t problems that need to be fully solved in the prototype, but they’re the lens through which the real API is being built.
What’s Next
This is still a prototype. The data is seeded rather than fully live and there’s a lot more to figure out - particularly around the saving score model, which is harder to get right than the spending side. The Open Banking integration via TrueLayer is the next meaningful milestone - once real transaction data is flowing in reliably the rest of the product becomes much easier to validate.
Further down the line, the plan is to bring stocks and shares into the picture as a third score. Your investments are part of your financial health just as much as your spending and saving habits - and right now most people have no clear signal on how that part of their portfolio is performing relative to their goals. A dedicated investment score would change that. Unlike the spending and saving scores which operate on a cycle, an investment score needs to reflect market movements as they happen, which means the data pipeline feeding it has to be genuinely real time. That’s another area where Go earns its place - its concurrency model handles the kind of continuous, high-frequency data ingestion that live market feeds require without breaking a sweat.
But the core is working. The two-score model feels like the right abstraction, the UI is legible and connecting to Monzo gives it enough real data to be useful for testing. That’s a good place to be at this stage.
Final Word - Why This Matters
The world is as financially uncertain as it has ever been. Current events are having a direct and immediate impact on the financial wellbeing of people across the world. Knowing where your money is going and whether you’re building any kind of cushion underneath you has never been more important - and yet the tools to help people do that are still, largely, not good enough.
Elaira is shaped by a few things that have come together for me personally: a love of fitness and health trackers, a day job in FinTech at Haysto and the recent experience of saving up and buying a house. Those three threads pulled me toward the same conclusion - that personal finance deserves the same thoughtful, score-driven approach that health apps have already proven works.
I want to build this in public. I’m also open to the idea of open sourcing it further down the line. If you have an idea, a bit of feedback or just want to follow along - get in touch or check back here for updates. I built the prototype in a few evenings - progress will be rapid ⚡️
