Keel

The problem

I built Keel because I was the user.

Fresh out of university, first full-time job, first credit card. No investments, no financial guidance, and no real understanding of what an installment plan does to a balance over twelve months. By the time I noticed something was wrong, I couldn't answer two basic questions:

How bad is my situation? And what do I actually do to get out of it?

That person is not rare. Every year a cohort of fresh graduates in Malaysia gets their first card, their first BNPL conversion, their first EzyPay plan — and no tool tells them where they stand until a collections message does.

Why the existing apps didn't help

There is no shortage of budgeting and expense-tracking apps. I tried them.

They all share the same shape: the user does the labour, and the app returns a chart.

You log every transaction, categorise it, keep the streak alive — and in return you get a pie chart of last month's spending. None of them told me how bad my situation was. None of them understood the context of my money. And none of them gave me a path out.

They also share a second shape, which took me longer to notice: the price of entry is your bank account. Link the feed, hand over every transaction you've ever made, and trust an app you found in a store with the most sensitive data you have. For a product aimed at people already anxious about their money, that's a strange first ask.

That gap became the product thesis:

Every other app makes you do the labour and gives you back a chart. Keel does the labour and gives you back a verdict — without ever seeing who you are.

The privacy position

Keel is built so that there is nothing to leak.

• No bank account linking. You enter your debts, installments, and balances yourself.
• No backend. Your financial data is stored on your device. There is no server holding a copy.
• No account. No sign-up, no email, no identity attached to anything.
• Anonymised context to the coach. The snapshot sent to the AI carries the shape of your situation — balances, rates, commitments — with no name, no account number, and nothing that links back to you. It runs through a paid API, so it isn't used to train models.
• No ads. No third-party tracking. The only analytics are anonymised interaction data, opt-in, used to improve the app.

This is the part of Keel I'd defend hardest, because it's the part that makes the rest of it honest. The app asks someone in a vulnerable financial position to be truthful about their debts. That only works if being truthful costs them nothing.

The constraint also made the product better. Manual entry means the user has to look at each debt as they enter it — which is itself the first step out of avoidance. And building without a transaction feed forced every design decision to answer the same question: what's the smallest amount of information that still lets the coach say something true?

The hardest decision: refusing to build the obvious things

The single most important decision in Keel was what I refused to build.

Keel does not have daily expense tracking. It does not have budgets. It does not have spending categories.

The one I wanted most: automatic payment detection through Apple Wallet and Google Wallet. Pay for something, and the app records it — no manual entry, no friction. Automation is the thing everyone says they want, and it demos beautifully.

I killed it. Detecting a coffee purchase tells Keel nothing about your debt profile. Expenses only matter to Keel when they land on a credit card, and there was already a simpler, more intuitive way to capture that: let the user update the card balance directly. One number, entered when it changes, versus an entire tracking subsystem inferring the same figure less reliably.

Once I framed it that way, the feature stopped being a hard call. It was a lot of engineering, a permissions ask, and a new privacy surface — to arrive at a number the user could just tell me.

Everything in the app exists to do one job: build a complete picture of your debt — balances, installments, rates, commitments — and hand that picture to an AI coach that reads your actual situation and tells you the path out.

You don't open Keel every day. You open it when you pay something down, and the picture updates.

This connects directly to the privacy position, and I only saw the connection partway through building. Daily expense tracking exists in other apps because they have your transaction feed — the logging and categorising are downstream of the bank connection. Refusing the connection removes the reason for the tracker. Two decisions, one root: Keel doesn't need to watch you to help you.

This was not an easy call. Trackers and budgets are the features people search for. They are what makes a finance app go viral. Choosing not to build them meant choosing to be harder to discover.

But I kept coming back to the same observation from using those apps myself: they are bloated to the point where I didn't want to use them. Dozens of features, an overwhelming interface, and — most importantly — none of it aligned with the job I needed done. More stats and more graphs do not help someone understand how bad their situation is or what to do about it.

So the rule became: if a feature doesn't improve the app's understanding of your debt, it doesn't get built.

What broke: the app knew things the coach didn't

The most instructive failure in Keel wasn't a crash. It was silent.

The snapshot drift. As I shipped features, each one enriched the financial profile the app records. But the snapshot — the payload passed to the AI coach — wasn't updated in step. The app was capturing more context; the coach was still reading the old, partial picture. Nothing errored. The coach just gave noticeably worse advice, and it took days to work out why. The fix was a full audit: trace every piece of data the app records, and rebuild the snapshot so the coach sees all of it.

The currency blind spot. Expanding beyond Malaysia, I built multi-currency support into the app — conversion, display, the lot — and didn't think about the coach at all. The coach had been written for Malaysian users. So the app would happily show a balance in IDR while the coach had no frame of reference for what that number meant. RM100 carried meaning; IDR 100 carried none. The fix was teaching the coach the user's country and currency context, not just the number.

Both failures are the same failure, and it's the lesson I took from the whole build:

In an AI product, the context payload is a product surface, not plumbing. Every feature ships twice — once into the app, and once into what the model can see.

{
"commitments": [
  { "label": "18% card", "kind": "revolving", "monthly": 250, "apr": 18 }
],
"runwayMonths": 4.2,
"topConcern": "18% card"
}

{
"currency": "IDR",
"market": "ID",
"commitments": [
  { "label": "18% card", "kind": "revolving", "monthly": 250000, "apr": 18 }
],
"runwayMonths": 4.2,
"topConcern": "18% card"
}

The open tension: monetisation

Keel launched on 5 July 2026. Five weeks in:

Product page views

359

First-time downloads

136

Paid subscriptions

0

Zero paid conversions is the honest headline, and I'll state plainly what it does and doesn't mean. At 136 installs, this isn't yet evidence that the monetisation is broken — a product converting at 1–2% would be expected to show roughly zero paying users at this sample size. What I have is not a conversion problem. It's a sample size that can't answer the question yet.

That distinction mattered, because my first instinct was to treat it as a product failure and respond by building. Expense tracking, budgeting, spending insights — package them as premium and ride the demand. Those features are what people search for, and they're what makes a finance app spread.

I decided against it. Not because I'd proven it wouldn't work, but because those features would make Keel worse at the one job it exists to do, and turn it into the kind of bloated app I built Keel to escape. Adding features I don't believe in to fix a number I can't yet read is the wrong trade.

The live tension: the demand signal says people want trackers; my conviction says trackers don't fix the problem Keel exists to solve. I chose conviction, and I'm aware conviction is cheap when the data hasn't arrived yet.

The genuine constraint right now is distribution, not product. 359 page views in five weeks is the number I should be working on. Everything below is untested until it's bigger.

What I'd test, roughly in order:

1. Distribution first. Get to a few thousand installs before drawing any conclusion about willingness to pay. Everything else is noise below that.
2. Store page legibility. No bank linking is Keel's clearest differentiator, but the listing states it as a feature rather than selling it as a reason to trust the app. A user comparing options may read it as less capable rather than safer.
3. Paywall placement. Does the coach's verdict — the actual moment of value — land before the ask, or after it?
4. Timing. Keel is bought at the moment of panic, and panic doesn't arrive on the day someone downloads an app. Reaching the user at the right moment may matter more than any feature.

Only after those would I revisit whether the product itself is the constraint.

Architecture

ON DEVICE                          │  EXTERNAL
User enters debts, installments    │
   ↓                               │
Financial profile (local storage)  │
   ↓                               │
Context snapshot ─ anonymised ─────┼──→  AI coach (paid API)
                                    │       ↓
Situation assessment + payoff path ←┼───────┘
                                    │
No account · No backend · No bank link

Stack: React Native / Expo (TypeScript, Zustand) · Cloudflare Workers, KV, D1 · Gemini API · RevenueCat

What I'd do differently

1. Treat the coach's context as a first-class contract. A schema, a test, and a checklist item on every feature — so the snapshot can never silently fall behind the app again.
2. Know what the data can and can't tell me. I read zero paying users as a product failure and nearly rebuilt the roadmap around it. At 136 installs, that number couldn't carry that conclusion. Knowing when a metric is too small to act on is a skill I underestimated.
3. Plan distribution alongside the build. I spent the build treating launch as the finish line. Five weeks of data made it obvious that shipping was the easy half.
4. Design for the moment of panic. The strongest version of Keel probably isn't a better app — it's an app that reaches the user at the point where the problem becomes real to them.

What this project taught me

The work I'm proudest of in Keel is the feature list I didn't build. Staying narrow under pressure — from the market, from competitors, and from my own urge to ship more — was harder than any technical problem in the app, and it's the reason Keel does one thing properly instead of ten things adequately.

The deeper lesson was about constraints. Refusing bank access looked like a limitation at the start. It ended up defining the product: it removed the need for a tracker, it forced every design decision to justify the data it asked for, and it's the reason a user can be honest with the app without risking anything. The best constraint in the product turned out to be the one I imposed on myself.