Runrate: The new way to budget

MOST BUDGETS LOOK BACK. RUNRATE LOOKS FORWARD.

Most budgeting tools tell you where your money went. Runrate is built around the question people feel in real life: What will my balance be after the next bill, paycheck, or planned purchase?

THE PROBLEM WAS TIMING

Traditional budgets compress life into monthly categories. Cash-flow stress is usually more immediate. Rent can land before a paycheck. A bill can move by five days. Two months with identical totals can feel completely different depending on sequence.

The product needed to turn a complex financial model into one clear answer: after every known event, what is the likely balance?

A LIVING FORECAST, NOT A STATIC BUDGET

Runrate starts with today's balance and applies recurring income, expenses, transfers, and one-off decisions in chronological order. The forecast makes three moments visible: where you are today, the lowest point ahead, and where you are likely to end up.

The critical interaction is “what if.” People can move a date or change an amount and immediately see how the forecast changes. The model stays rigorous; the interface stays legible.

The forecast exposes today’s balance, the lowest point ahead, and the future balance—and supports keyboard inspection.

DESIGNING THE LEDGER AS AN EXPLANATION

A chart shows the shape of the future, but the ledger explains why. Every row includes the balance after that event. Past-due, pending, ignored, and low-balance states are visually distinct. Keyboard navigation and responsive behavior are specified alongside the visual rules.

ONE SYSTEM ACROSS PRODUCT, MARKETING, AND AI

I built Runrate's design guide as production HTML, not a separate Figma library. It documents tokens, typography, components, states, accessibility, responsive behavior, product patterns, and Web-to-iOS correspondence. The examples can be tested in the browser, and Production Web remains the source of truth.

I also point the project's agent instructions at the guide. Before an agent changes a customer-facing surface, it is instructed to consult Foundations, Components, and Patterns, and reuse the system before extending it. The same rules govern product features, email templates, and marketing creative.

The system preserves shared meaning across platforms without forcing identical rendering. Web uses the production tokens; iOS maps the same roles to native materials, Dynamic Type, touch targets, and safe-area behavior.

SHIPPED ACROSS THE STACK

Because I own both product design and implementation, decisions move directly from intent to working software. The product spans native iOS, a Swift/Vapor API, PostgreSQL persistence, App Store subscriptions, analytics, and a SvelteKit web surface.

That end-to-end ownership matters here: forecast logic, language, component behavior, and visual hierarchy stay aligned across every layer.

RESULTS SO FAR

Public metrics as of July 21, 2026

• 79% of launch-quarter paid users were still active (67 of 85).

• Paid subscribers averaged 39–44 sessions per month from March through May 2026.

• Active paid users had a median subscription age of 603 days.

• The product had observed 70+ country/region locale codes before systematic global growth.

The scale is still early. The signal is sustained use: when Runrate clicks, people keep coming back.

WHAT I LEARNED

The hard part was not drawing a forecast. It was deciding which pieces of a complex model needed to be visible so people could trust it without feeling buried in detail.

The design principle that held through every surface was simple: show the future clearly enough that someone can act before a problem arrives.

Product and public metrics: https://myrunrate.com · https://apps.apple.com/us/app/runrate/id6476164801

Runrate — Designing a calmer way to see future cash flow