Personal finance apps have a graveyard problem. Intuit shut Mint down and pointed its users at Credit Karma. Money Dashboard closed its apps, saying it couldn't find a sustainable business model. Moneyhub announced it was closing its consumer app to focus on B2B. These weren't small teams that ran out of runway on a flawed idea. They were capable, funded operators, and the category beat them.

The reason is arithmetic. Every connected user costs money to serve, because bank and broking data feeds are priced per user. Willingness to pay is low. And people don't open these apps very often. You check your net worth when something happens, or at the end of the month, or when you're anxious. Low frequency means weak habits, and weak habits mean churn.

I'm building one anyway: a read-only app for people whose money is spread across several banks, brokers and pensions. It shows net worth, what changed and why. My bet is that AI can fix the frequency problem by giving people a true, useful reason to open the app between the moments they'd check anyway. That's the only meaning of "AI-driven growth" I care about. This article is about how I've designed for it, and what building it taught me about models, attention and money.

The app hasn't launched yet, so there are no retention curves here. This is design and observation, not results.


The growth problem is frequency, not features.

Most growth thinking assumes users show up and the job is converting them. In a low-frequency category, the job is earning the next visit. So the north-star metric I picked isn't installs or daily activities. It's weekly active users who have linked at least two institutions and viewed an explained insight. "Explained" is doing real work in that sentence. A number nobody understands isn't value, and a dashboard that only shows totals gives no reason to come back tomorrow.

Two onboarding rules come from the same thinking:

  • Value before linking. You can add a manual asset and see a net-worth view before you trust the app with a bank login. The target is value in under ten minutes.
  • Cadence after value. The app asks how often you want to hear from it only after it has shown you something worth hearing. In the code's own words, "a cadence chosen before there is anything to report is a guess."


The coin flip

Ask a model "is today worth a notification?" and on borderline days you get a coin flip. A 0.3% move might get a push on Monday and an identical one nothing on Tuesday. Users don't read that as intelligence. They read it as an app that can't make up its mind.

So the model never decides whether the morning digest goes out. Code does, against a threshold the user picked: every day, moves of 0.25% or more, or only moves of 2% or more. On quiet days the model isn't even called. It decides only what to say. The words can change every day, but the moment can't.

Nudges are the exception, because nobody asked for them. There the model decides whether anything is worth saying, looking at its last ten nudges and whether you ignored them. If it declines, nothing is sent and there's no backup message. The digest, which you did ask for, falls back to a plain template if the model fails. Who asked decides the fallback.

Let the words wander

One wrong number destroys trust in a finance app, so the rule I wrote into the advisor's prompt is "LLM for words, ledger for numbers." Code computes every figure. The model picks which ones matter and writes the sentence, and a verifier rejects any number that didn't come from code. Every money figure on screen is also tappable, down to the transactions behind it.

The side effect surprised me. Once the numbers are deterministic, the model doesn't need to be. The instinct in finance is to set temperature to 0, but on Gemini 3 that's harmful. Google's guide warns that going below 1.0 "may lead to unexpected behavior, such as looping," and I watched an answer loop until it hit the output limit. With the ledger holding the numbers, the words can wander as much as they like.


What models do with numbers

Working this closely with a model on financial text, a few behaviors stood out. None of them is a bug in the usual sense. They're what these models are like, and you design around them.

Models bend numbers toward a better sentence. Given a recurring charge with a £268.09 monthly estimate, the model wrote "£265 … in a single week." It rounded, rescoped and relabeled, all to make a punchier line, even though the tool's own description said not to use the estimate that way. The commit message I wrote about it is the best one-line summary of prompt engineering I know: "a prompt warning is not a guard." The fix was to stop handing the model numbers I didn't want it to say. Projections no longer appear in what it sees.

Models follow your examples over your rules. Write "never use format X" and then show an example in format X, and the model will use format X. One reviewer's note on a prompt puts it as "A few-shot example beats a prose prohibition." With a validator in the loop, that contradiction doesn't produce one bad message. It produces a rejected draft and a paid retry on every single run. In practice, the examples in a prompt are the spec, and the rules are commentary.

Models repeat themselves unless they can see their history. Six "roast my spending" sessions in a row opened with the same joke. More on roasts below.

Every guard fails in two directions. When an extraction model counted a pension portal's own total rows as accounts, the obvious guard was arithmetic: drop any row that equals the sum of its siblings. I didn't ship it, because accounts holding 100, 200 and 300 pass that test and all three are real. Removing a genuine account from net worth is "the same defect pointing the other way." Instead, the model has to label total rows in a required field, and storage acts on the label. I tried a currency-aware verifier too, parsing the currency symbols in answers. It couldn't work, because "$" doesn't tell you whether it's US or Australian dollars. Any setting was "either too strict… or too loose."

The general lesson is that the two failure directions aren't equally visible. A wrong number on screen gets noticed and reported. A real account silently dropped from a total leaves nothing for anyone to see. So when a guard has to err, I make it err toward what's visible and correctable. A transaction the model hasn't classified still counts, and an answer that fails verification once is retried, then published and stored as unverified rather than swallowed. Unverified answers never feed later turns, though, because a figure that slipped through once would otherwise be treated as grounded for the rest of the conversation.


Comedy as a retention feature

The feature I didn't expect to build is "roast my spending." You ask, and the advisor makes fun of your spending habits using your actual transactions. It's also the one feature in a private product that people might actually share. Nobody posts their net worth, but a good roast is the kind of thing people screenshot.

Comedy turned out to be one of the hardest things to make safe:

  • It roasts the spending, never the person. That means no jokes about bodies, health, intelligence or relationships.
  • It skips some purchases entirely. Anything that signals "safety, health, distress or hardship" is off the table, for example a locksmith after a break-in or a medical charge. The prompt's phrasing: "mocking someone's anxiety is not a bit."
  • Every joke has to be true. It can only cite real transactions from roughly the last month, and at most two figures per beat. A code check enforces the cite cap. In a repeated test harness the model exceeded it in 3 of 12 beats before the check and 0 after.
  • It can't recycle material. Every bit it uses goes into a ledger, and that target and angle are off-limits for 14 days unless the joke explicitly calls back to the repetition with fresh data.

Humor is also expensive. One long roast turn used about 303,000 input tokens, roughly $0.50, before tightening brought it down to 117,000–194,000. That brings up the part of AI-driven growth nobody puts on the slide.


Engagement now has a marginal cost

In classic software an engaged user costs you almost nothing extra. With AI features, your most engaged users are your most expensive ones.

Some real numbers from my app:

  • A proactive nudge costs about $0.0045 to compose.
  • An advisor turn on the top model costs about $0.19.
  • The brokerage data feed costs $2 a month per connected user, before you've shown them anything.

My planning estimates put the core product's full cost at about £1.50–2.50 per paying user per month. Add the advisor and it becomes £2.50–5.50. Bundle the advisor into a normal annual subscription, pay app-store fees on top, and at the heavy end of usage the contribution margin goes to roughly zero or negative. So the advisor is a separate, higher tier. A web checkout recovers more per user per year than the entire cost line, which makes it the biggest margin decision in the plan.

The same math rules out the classic growth playbook. At £65 to acquire a paying user, the lifetime-value-to-acquisition-cost ratio comes out around 1.2:1, far below the usual 3:1 bar. Growth has to be organic, which loops back to the start of this article: the product has to earn its visits.


The advice line

The most engaging question a finance app can get is "should I sell this?" It's also the one it can't answer. In the UK, recommending a specific investment to a specific person is regulated advice.

So the advisor describes, quantifies, explains and teaches. It doesn't tell anyone to buy, sell or hold a specific security, prescribe an allocation as a call to action, or recommend a product. Where a human adviser would make the call, it lays out the numbers and the evidence and suggests discussing it with a regulated adviser. Its disclaimer says plainly that this is general information based on your own data, not regulated advice.

The same caution shapes personalization. The advisor remembers what you tell it: your age, your goals, your assumptions. It never saves an inference you didn't state, and it never saves sensitive categories (health, religion, sexuality, politics) at all. Chat threads expire after 30 days. Inferred personalization is where AI growth decks get exciting, but in finance it's also where things get creepy. Stated preferences are less clever and far more trustworthy, and a new app doesn't have the data to infer much anyway.

Experimenting with 150 people

The standard advice is to A/B test everything, or better, run bandits. My planned beta is 50 to 150 hand-picked people. Detecting 30-day retention moving from 30% to 35%, at the usual 5% significance and 80% power, takes about 1,380 users per arm. A bandit doesn't rescue you. It moves people to the apparent winner sooner, and with 150 users the apparent winner is mostly noise.

So I've built for a world without statistical power:

  • Replays against real history. The digest was replayed over 40 days of real data and checked for exact reconciliation.
  • Repeated runs. A single run of a conversation tells you almost nothing about a stochastic system, so the conversation harness runs each scenario several times.
  • Reading real conversations. At one point that meant all 78 production chat threads, 336 messages. They show you what a test suite can't: what people actually ask, and where the answers fall short.
  • A claims review for every user-facing sentence. Each review asks one question: can the code prove what this sentence says? There have been 57 of these reviews, and CI pins 196 strings by hash to the exact text that was reviewed, so nobody can quietly reword a claim. One review summed up the whole philosophy: "Fluency is not truth."


The model isn't the moat

Here's the uncomfortable part of my own strategy document. The AI advisor, the feature most people would call the product, is the most copyable thing I have. Any incumbent can wire a frontier model to a bigger data graph in a quarter, and frontier models get cheaper and better for everyone at once.

What's hard to copy is everything underneath it:

  • Wealth-grade data: real cost basis, foreign exchange handled properly, positions resolved to the actual security, pension vesting.
  • The verification gate that keeps the model from saying a number it can't prove.
  • The drill-down that lets a user check any figure against its source transactions.

I haven't seen a competitor ship the verification gate and mandatory drill-down together. That's the bet.

Merchant names are a small example of where the line falls. Raw bank descriptions are a mess, and the model is genuinely better at cleaning them than rules are. On one account it grouped 572 raw descriptions into 296 merchants, replacing 506 lines of hand-written cleanup code. But its prompt carries a rule I'd put in any extraction prompt: "An honest raw descriptor beats a plausible fabrication every time." The model handles the words, and it's allowed to say "I don't know."

What AI-driven growth actually means

The original pitch for AI-driven growth is a model that learns your users and adapts the product to them. In a low-frequency, high-trust category, I think it's something more modest and more useful:

  1. Give people a true reason to come back. Compute the facts in code. Let the model decide which one matters and say it well.
  2. Spend attention like money. Make silence the default, let users choose the thresholds, and give unsolicited messages no fallback.
  3. Make every number checkable. Trust compounds, and a single wrong figure costs more than a hundred good insights earn.
  4. Price the intelligence. Engagement isn't free any more, so the features that cost the most should carry their own price.
  5. Accept that you can't A/B test your way there yet. Replay, repeat, read every conversation, and review every claim.

The model is the easy part. Everything around it is what makes it worth opening the app for.