Most personal finance tools are excellent at telling you what you already spent and useless at telling you what happens next. LifeOps is the other way round: a private forecasting product that models income, commitments and scenarios forward over years, and answers questions like whether a decision is survivable — with the uncertainty shown rather than hidden.
THE PROBLEM
Budgeting apps categorize the past. The decisions that actually matter — can we take this risk, when does this become affordable, what breaks if income stops — are forward-looking questions no ledger answers.
Spreadsheets are the default tool for this, and they are single-scenario by nature. Modelling an alternative means duplicating the sheet, and comparing three futures means three sheets that immediately diverge in their assumptions.
Existing tools that do forecast tend to project a single confident line into the future, which is the least honest possible representation of something driven by variable income and irregular expenses.
Financial data is the most sensitive category of personal data there is, so anything requiring bank credentials starts from a trust deficit that a small product cannot easily overcome.
CONSTRAINTS WE WORKED UNDER
WHAT WE DID
Modelled finances as accounts, recurring flows, one-off events and rules, so a forecast is a projection of explicit objects rather than an opaque calculation.
Built scenario branching — fork the baseline, change assumptions, compare futures side by side without duplicating anything.
Added probabilistic projection over variable inputs so the output is a range with likelihoods, not a single confident line.
Made every projected figure traceable back to the assumptions that produced it.
ARCHITECTURE
01
Accounts, recurring flows with schedules, one-off events, and rules that fire on conditions. A forecast is a deterministic walk over these objects, which is what makes any figure explainable — every euro traces to an object and a date.
02
Time-stepped simulation over the object graph, handling schedule irregularity, rule interactions and account interactions. Runs are deterministic given a seed, so a shared projection reproduces exactly.
03
Scenarios are diffs against a baseline rather than copies. Changing a shared assumption updates every scenario that inherits it, which removes the drift that makes duplicated spreadsheets useless within a month.
04
Variable inputs carry distributions rather than fixed values, and projections run many times to produce percentile bands. The interface shows the range and the likelihood of specific outcomes — the questions people actually have.
05
Account-gated, no third-party credential storage, data entered and controlled by the user, with export available. The product assumes a user who wants to leave, and is built so leaving is easy.
KEY DECISIONS
WHY
Aggregation buys convenience at the cost of holding the keys to someone's financial life. For a forecasting tool, the marginal accuracy did not justify the trust and liability burden.
TRADE-OFF
More setup effort for the user, and balances need periodic updating. It also means the product never becomes a breach target for credentials it does not hold.
WHY
Copied scenarios drift. If a shared assumption changes and only three of five scenarios get updated, every comparison after that is quietly wrong.
TRADE-OFF
A more complex resolution layer, and inheritance rules the interface has to make visible rather than clever.
WHY
A single projected line implies precision that no multi-year financial forecast has. Showing bands changes the user's question from 'what will happen' to 'what am I exposed to', which is the better question.
TRADE-OFF
Harder to present and harder to read at a glance. Worth it — a point forecast that turns out wrong destroys trust in the whole product.
THE HARD PARTS
Monthly-salary assumptions fail immediately for freelance or variable income. The schedule model had to handle genuinely irregular flows with distributions rather than treating them as a monthly average, which is where the probabilistic layer earned its cost.
Early projections were correct and unconvincing, because the user could not see where a figure came from. Making every projected value expandable into its contributing objects changed how much people trusted the output more than any accuracy improvement did.
Cheap scenarios meant users created a dozen and lost track of what each represented. Naming, inheritance visualisation and archiving turned out to be product features, not housekeeping.
HOW IT RAN
01
Accounts, flows, events and rules, plus the deterministic projection walk that turns them into a forecast.
02
Diff-based branching, inheritance resolution and side-by-side comparison views.
03
Distributions on variable inputs, repeated simulation, percentile bands and outcome likelihoods.
04
Traceable figures, export, account security and the privacy posture documented for users.
OUTCOME
Multi-year
Forecast horizon with irregular flows handled natively
Ranges
Probabilistic bands instead of a single confident line
Traceable
Every projected figure expands to its assumptions
0
Bank credentials stored
Privacy posture, decided up front.
A forecasting tool that answers forward-looking questions honestly — including how uncertain the answer is.
Scenario diffing is what replaced the spreadsheet. Comparing futures stopped being a copy-paste exercise, which is the moment the tool became worth opening.
The privacy stance simplified the product as much as it protected users: no credential vault, no aggregation vendor dependency, no breach surface for keys the product never holds.
STACK
APPLICATION
DATA
MODELLING
SECURITY
HANDOVER
