A budgeting app that tells you you’re okay before it tells you anything else.

Most budgeting tools are built around limits. Categories get ceilings, progress bars fill up and change color, and an alert arrives when you go over. That design assumes the problem is missing information. The research on money and emotion points somewhere else: people tend to look away from their finances exactly when things get hard.

Put together, these sources suggest an uncomfortable inference: if people already avoid financial information when they expect bad news, an app that greets a rough week with red overages is working against its own goal. It teaches people to stop looking. That’s the bet Keel is built on. It’s an inference from published research, not something I’ve measured, and the testing plan in section 12 is designed to check it.

I didn’t run interviews for this project. Instead of inventing users, I did a desk review: what published research says about money and attention, and how four products position themselves.

Competitor notes come from each product’s own public site, published method, or announcements, read in October 2026. I didn’t hold paid accounts in all four, so this is a review of stated positioning and documented patterns, not a hands-on teardown. If I were doing this inside a team, the next step would be interviews with five to eight people who stopped using a budgeting app, which is the group this concept most needs to understand.

In the material I reviewed, the headline is usually a balance, a remaining budget, or a set of category totals. YNAB’s Age of Money is the closest precedent to what Keel does, because it measures money in time instead of dollars. The difference is direction. Age of Money looks back at how long money sat before it was spent. Keel’s reading looks forward: if nothing else came in, how long are you covered? That one forward-looking answer, shown before any detail, is the product.

Adults in the United States and Canada who are paid on a regular cycle and want to know, before anything else, whether they’re okay until the next payday. The two countries share the dollar sign and most of the vocabulary; where they differ, the prototype follows the reader’s region: chequing or checking, paycheque or paycheck, CAD or USD. It picks the region from the browser’s language settings, and the Guide has a switch.

Assumption-based personas, built from the research above to keep design decisions concrete. They aren’t composites of real interviews; the people, places and details are illustrative, and each one lists what a study would need to confirm.

Inferred from the published research and product material above, not from interviews. They’re the hypotheses the study in section 12 is designed to test.

The journey Keel is designed around. Each stage pairs what the person needs with where it tends to break, from the evidence above, and the screen that answers it. It’s a hypothesis built from research, not an observed journey.

A comparison of what each product leads with in its own public material, read in October 2026. Some may offer similar features deeper in the product; this compares positioning, not a feature audit.

What only Keel leads with, in the material reviewed:

• → A forward-looking date as the first thing you see
• → Spending in days, not overages
• → A preview of any purchase or plan before anything changes
• → Both countries’ vocabulary and currency from the start

From that, three principles. Each one is specific enough to say no to something, which is how I checked it wasn’t a generic UX platitude.

These are proposed measures, written before any data exists. None of them has been measured. They’re here so the testing plan has something specific to check.

Four tabs, and one rule underneath them: any action that moves money shows its effect on the reading before it happens, and returns you to it after.

Onboarding collects exactly the three inputs the reading needs (accounts, recurring bills, payday) and nothing else. Goals got a plain name. I considered “Harbors” to extend the nautical theme and dropped it: a metaphor should explain the product, and a tab label that needs explaining is costing clarity to buy charm. Plan is the newest tab, added in the motion pass so people can try a change before they commit to it. The diagram draws itself as you reach it, in the same order you’d move through the app.

Grayscale and boxy on purpose, so the only thing being judged was structure. The first home screen was a dial, and it’s here because the reason I dropped it shaped everything after.

Three structural changes happened after these sketches, all from my own review of the rendered screens (there’s no user testing yet, and section 12 says so). They’re documented with before and after in section 12’s change log, but in short: the reading moved out of a card and onto the page itself, category colors became tints of one ink instead of several hues, and the purchase check’s “ghost” keel was redesigned because the first version was illegible at phone size.

The brief for the identity came straight from the concept: grounded instead of urgent, one confident accent instead of a traffic-light system. Keel has had three identities. The first two were warm (the second, Mineral & Ember, set porcelain and stone against one oxidized ember accent). Reviewing it next to the apps Keel would sit beside, I found it read as lifestyle, not finance. The third, Harbor & Signal, keeps the restraint and moves to a cool fintech palette: grey-white surfaces, deep navy type and one lime signal, with a navy night for dark mode. The source palette is MP174 by Alex Cristache; I extended it with accessible greys, status colors and a dark theme.

Every pairing is checked by a script (source/contrast_audit.py) against WCAG 2.2: 4.5:1 for text under 1.4.3, and 3:1 for control boundaries, focus indicators and chart marks under 1.4.11. Decorative hairlines are listed too and marked exempt, with the reason, rather than quietly left out.

The audit shaped the Harbor & Signal tokens. Signal Lime is 1.1:1 against the light surfaces, so on light it is only ever a fill behind navy (13.7:1), and wherever it has to be seen as a shape (the hull, the lime blocks in the illustrations) it carries a navy edge that does the contrast work. The buttons are translucent glass, so the script composites each button’s fill over every surface it can sit on before measuring the label: 8.97:1 at the lowest for the primary button and 13.81:1 for the secondary, whose edge measures 3.66:1 or more. People who ask their system for less transparency or more contrast get solid buttons.

The table below is generated from the script’s output for both themes: 94 pairings, none failing. The theme button at the top of the page switches the table and the whole case study.

Naming tokens “canvas, surface, accent” doesn’t make a screen 60/30/10. So I wrote a second script (source/weight_check.py) that takes rendered screenshots and assigns every pixel to its nearest palette role. Text and chart marks are counted separately as content; the split is over the color fields.

The first measurement of the home screen came back 30% canvas, 68% surface, 2% accent: the reading lived in a card that filled most of the phone, so the structural color had become the background. I took the reading out of the card and set it directly on the canvas, let the water band carry the surface, and turned the tab bar into canvas with a hairline. The re-measure: 64 / 34 / 2. These measurements and both images below are from the second identity, Mineral & Ember; the layout fix carried over to Harbor & Signal unchanged.

Two honest notes on the numbers. I treat 10% as a ceiling for the accent, not a quota: it only appears where there’s something to do, and I didn’t add accent to a screen just to hit a number. And list-heavy screens (Bills, Activity) run closer to 50/50 because every list sits on a surface with real row dividers instead of floating on the page. I chose structure over the ratio there, and I’d revisit it with real content lengths.

Switzer, a neutral grotesque, does everything, in three levels. Display is Regular with tight leading and no added tracking, so the headlines and the reading’s date stay calm at large sizes. Data is Medium with tabular figures, so amounts and dates line up in columns. Body is Regular from 14 to 17px for UI and prose. Headlines use balanced wrapping so no line ends on a single dangling word, and body copy holds to about 66 characters a line.

Instead of a new decorative shape per screen, the whole system is built from one construction: a horizontal line (the waterline, which is always payday), a hull resting on it, and a weighted keel hanging below. Depth below the line means room. Every appearance of the motif follows the same rule, so it never turns into decoration.

A small set drawn on a 24px grid with a 1.75px stroke and round joins, matching the weight of Switzer at UI sizes. Only three icons ship in the prototype, because there are only three places to go. The Steady icon is the motif itself.

Every illustration in Keel is built from the same small set of objects: a beam, a pivot, a plinth, blocks and one lime sphere, resting on a ground line. They are 3D-inspired rather than 3D: drawn in oblique projection with flat shading, so they stay sharp, tiny and animatable as vectors.

Five materials, each a step of a Harbor & Signal color, each drawn with exactly three tones: a lit top, a front, and a shaded side. On light, every solid gets a thin navy edge, because white and lime faces are about 1.1:1 against the canvas. No gradients anywhere except contact shadows, and no gloss.

• Oblique projection. Depth is a fixed offset up and to the right (16:−10 for objects, 22:−14 for plinths), so every object agrees on where the viewer stands.
• One light. Top faces are lit, right faces are shaded, always. Dark mode keeps the same light and lowers it, rather than inverting it.
• Contact shadows only. Soft radial shadows under things that rest on other things. They are the only gradients in the system, and they make weight readable.
• The lime is always last. In every composition the lime element is the final one to move, so the eye ends where the meaning is.

There’s no After Effects export path in the environment I built this in, so the animation is written directly as Lottie JSON from a Python script (source/gen_lottie.py, and for everything since, source/lottie/build.py), the same approach I used for Clearstep. The boat is drawn as a cutaway so the keel shows below the water: the hidden thing made visible, which is the whole product in one picture.

Three colors only per theme: Deep Navy, Signal Lime and Mist Blue in light (the lime hull outlined in navy); Fog White, Signal Lime and Night in dark. Lottie colors are baked into the file, so each theme has its own JSON with identical keyframes, and the page swaps them when the theme changes. The boat starts heeled 9° and rocks about a pivot near the center of buoyancy, so the hull and keel swing in opposition like a real righting moment. Each swing keeps about 62% of the last one’s amplitude and is slightly quicker, which is what damping looks like. It’s level by frame 180 and then holds still for two seconds before it stops. I rendered and reviewed every keyframe before using it; the strip below is the live file, not screenshots.

Every animation in Keel has to answer one question: what does this movement help someone understand? If the answer is “nothing, it’s nice”, it doesn’t ship. Five principles decide the rest.

This is the part of the identity I’d most want to defend in a review, because the pacing is an argument, not a style. In my previous motion study, Clearstep, the payment confirmation uses a 350ms curve with overshoot (cubic-bezier(.17,.89,.32,1.28)). That’s right for a checkout: the moment is a small win and should feel crisp. Keel’s moments are different. A reading changing isn’t a win or a loss, it’s information about your footing, so it should feel like weight finding its level: slower, decelerating, with at most one small overshoot that damps out.

All sixteen animations, each with the problem it solves, how it behaves, and what it’s made of. They play once as you reach them; use the controls to replay, pause, or step through the storyboard. The storyboards are frames of the shipped files, not sketches.

The same components the app uses, pulled out so you can trigger them. Try them with motion reduced too (the switch in the header): every one still changes state, it just doesn’t travel.

Four components respond to state rather than play once, which is what Rive state machines are for. I don’t have the Rive editor where I built this, so I wrote the files the way I wrote the Lotties: in code. A small Python writer (source/rive/rivewriter.py) emits the Rive binary format directly, using the type and property keys from Rive’s open-source runtime, and source/rive/build_rive.py authors the four components with light and dark artboards. Each one below is a real .riv running in the Rive web runtime, driven by the same sample data as the app.

One decision made them exact rather than approximate: every number input drives a 1D blend state between two poses keyed at the ends of its range, and every keyed property is linear in that input. So 9 days of room draws at exactly 9 days, and $175 more a paycheck draws every step of the plan exactly. The springs and settles stay in the host, which eases the input, as the web versions already did.

Why the app still ships the web versions: the four files total 24 KB, but the Rive runtime is 51 KB plus a 431 KB WebAssembly module (gzipped). The app’s whole first load is about 110 KB. The files use the same input names as the web implementations, so the swap is a loading decision, not a redesign. What changed from the spec while authoring: the ghost needed its own depth, so the Equilibrium Indicator gained a ghostValue input; and direction turned out to be unnecessary, because blending between poses reverses exactly on its own. It stays as an input so the interface matches the spec.

Four tabs, each built around one question. Steady: am I okay? Spending: where did it go? Goals: what am I setting aside? Plan: what if I changed something? These are live captures of the prototype in the next section, with its sample data.

Explore how financial clarity comes to life through thoughtful interaction, motion, and visual design. This is the real app, not a mockup: every figure is computed, every change carries through, and your changes are kept on this device until you reset.

Opened on its own, the prototype greets first-time visitors with a short welcome, an overview of the four tabs and an optional eight-step guided tour that points at the real interface; returning visitors go straight to the app, and a Guide button on every screen restarts the tour. The copy embedded here skips the welcome so the walkthrough on the right can drive it.

Starting today, Keel walks forward one day at a time, subtracting your usual daily spending and any bill that falls due, and ignoring future income. The last day the balance stays above zero is the “steady through” date. Payday is then compared to it: the difference is the keel depth.

Ignoring income is deliberate. It means the reading answers “how much room do I have if things go wrong”, which is the question underneath money anxiety, rather than restating a balance. It’s also the decision I’m least sure people will understand without being told, which is why it’s the first risk in the testing plan.

The components the app is made of, live. They read the same tokens as the app, so the theme and motion switches in the header apply here too.

Nobody outside this project has used the prototype yet. So this section is two honest things: the test I’d run next, and the changes that came from my own review of rendered screens. Neither is presented as user research.

Every screen and animation was rendered headless and reviewed before I called it done. These are the design changes that review caused. They’re real, but they came from me checking my own work against my own criteria, not from users.

What I wanted this project to show is that the brand and the product can be the same decision. The lime hull on its navy edge, the date set large in Switzer, the 900ms settle and the “weight, not walls” copy aren’t a skin on top of a budgeting app. They’re the product’s argument, made visible.

The test I used at the end was to hide the name and ask whether this could be any budgeting app’s case study. I don’t think it could. The headline metric is a forward-looking date that ignores income on purpose. The visualization encodes exactly one thing, room past payday, as the depth of a keel below a waterline that always means payday. Spending is shown as days of room rather than overages. The motion is slower than a fintech default for a stated reason. Take away “Keel” and those choices still only belong to this idea.

Keel set out to answer one question before anything else: if nothing else came in, how long are you covered? It now exists as a working prototype in React with a guided tour, a design system with 94 audited contrast pairings, and a motion system of Lottie and Rive files written in code, designed for people in the United States and Canada. What it doesn’t have yet is evidence from people using it. Everything below is what Keel could deliver in use, written as hypotheses with the measure that would prove or disprove each one.

• Talk to people before designing the reading. I’d start with interviews with people who quit budgeting apps, and I’d expect them to change the metric. Desk research told me what to worry about; only people can tell me what the number should be called.
• Pressure-test the calculation with someone who builds financial products. “Usual daily spending” is doing a lot of quiet work. Irregular income needs its own model, not an average.
• Design the bad day properly. The prototype handles “short before payday” with calm copy. A real version needs a path to do something about it, designed with the same care as the happy path.
• Move the motion into real motion tools. Writing Lottie and Rive in code forced me to understand both formats deeply, and it makes every animation reproducible. But in After Effects and the Rive editor I’d iterate on curves with a motion designer in minutes instead of rebuilding them, and I’d give the Rive pieces the depth and texture the editor makes easy.
• Run the accessibility audit with people, not just scripts. Ratios pass, but a screen reader pass on the reading and the keel visualization is the real test.

This project is the public, inspectable version of work I’ve done in professional settings, like scenario-based testing and interviews with technicians and clients, where the findings stayed internal. Keel is the version I can show all the way through.