Reign. Designing a financial agent people can trust with everything.

The problem

People who take money seriously spread it across a dozen accounts, a few apps, and a spreadsheet. I was one of them: 12 accounts, 3 apps, 2 spreadsheets. Every tool showed me balances. None answered the question I cared about: when can I stop working, and what should I do next? I’d tried Mint, YNAB, and Monarch. Each had strengths, but none could tell me whether I was on track.

One real number instead of a dashboard

Reign leads with a single answer, your projected retirement age, and everything else on the screen supports it:

• Your monthly retirement income and the gap you still need to close
• Two or three observations specific to your accounts
• The highest-leverage action: the one thing that moves your number most
• A scenario that makes it concrete: save $350 more a month, retire years earlier

The free check takes 3 minutes and needs no account. People see their number before Reign asks them to connect anything, so it earns trust before it asks for it.

Designing for trust

Asking people to connect every account is the hardest ask in fintech. I treated trust as a product decision, not a security page.

• Read-only by design. Reign can see every account and move none of them. That limit shapes everything the agent can promise and say.
• Every service, named. The page lists each company that touches your data and what it can and can’t see: Plaid holds bank credentials, Stripe takes payment, Supabase stores encrypted numbers, Gemini writes the advice and trains on none of it. “That is the entire list.”
• Clear limits. Reign says plainly it is not a bank, a lender, or a licensed advisor.
• A calm visual voice. The brand reads like a private banker’s ledger, not a fintech dashboard: oxblood, warm paper, and Geist type, with landscape imagery that suggests the long view.

An agent that speaks up only when it matters

You build your plan with Reign in conversation and can ask it anything, any time. After that it works in the background. Daily jobs refresh your data and a Gemini review writes the messages: a brief every Monday, an alert when a balance runs low or a bill is about to miss, and bills spotted before they land. The design challenge was restraint. An agent that talks too much gets ignored, so every message has to be specific to your money and tied to an action.

An AI that explains the numbers but never makes them

Reign uses Google Gemini for its reviews and its chat. Early on, I let the model run its own calculations, and that caused problems. So I split the jobs: Reign’s system derives every number deterministically and hands those numbers to the AI, which only writes the narrative around them.

Chat raised the stakes. It had to follow the same rule, plus limits on which topics it covers and what it may say about money under the law. I couldn’t think through every edge case alone, so I gave my agent the goal instead of a list of tasks. Working inside the rules and guides we had already set, it coordinated dozens of subagents to plan, build, test, and review the chat system, including heavy use and adversarial testing.

The agent came to me for the decisions that mattered:

• Copy, voice, and tone
• Any database change or migration
• “What if” and “can I afford this” questions
• Any request to loosen a hard rule

One of those requests shows how the boundary works. The hard rule is that chat never calculates numbers. But someone might ask, “My mortgage is at 7%. If I refinance to 4%, what happens to my payment and my total interest?” Reign’s system doesn’t compute that. So I allowed one narrow exception: chat can work out the answer from inputs Reign already holds, but only inside that conversation. The result is never written to Reign’s database.

I reviewed the rule sets, the legal and adversarial prompts, the test transcripts, and every major change to chat. The work took 15 days and 14 escalations, about one a day.

A design system synced from code

I built Reign’s brand and design system, then synced the system from production code so the design file and the shipped product can’t drift apart. Design QA happens as I build, not after.

How I built it

Reign is the most substantial thing I’ve built with AI, and I built it in two very different phases.

Phase one: manual and slow. I started Reign during Build with Gemini | XPRIZE, a three-month hackathon. I wrote the PRD, prompted Claude Code to build, reviewed the PRs, and designed screens in a hurry. The scope was too wide: bank accounts, transactions, retirement math, forecasts, and plans all at once. Bugs piled up, and the same number could change from one screen to the next. After more than a hundred hours, the math still didn’t add up.

Two changes turned it around. First, spec-driven development. A light version covering the core functionality, the math, the principles, and the rules nearly eliminated the bugs and inconsistencies. Second, capacity, and what I did with it. I had been rationing my AI usage. When my plan ran out three days before the deadline, I upgraded, and I spent the extra capacity on checking the work: independent review and QA agents on every issue. Feature pace rose only modestly, about 1.4×. What changed was rigor: defects found and fixed each week went up about 4×, and shipping went from manual pushes to about 18 checked releases a week.

Phase two: a system, not a prompt. After the hackathon I kept building on a branch, and I developed a set of guides, rules, and agent loops that carry work from a GitHub issue to production. Specs, skills and context files, and persistent memory keep each session on the same page. To start work I open my IDE and tell the agent to start a new session; it picks up from the issues logged on GitHub. A cloud setup lets me keep shipping from my phone. I still kick off the work and set the direction, but the speed and quality are far beyond where I started.

Where it stands

Reign is live at meetreign.com with real accounts and real payments.

What I learned

• Trust comes from constraints you design in, not reassurance you add to the UI.
• One number beats a dashboard when it comes with the next step.
• Let the AI narrate and let the system calculate.
• Hand an agent a goal only after the rules exist. It worked largely on its own for 15 days because the guides and hard rules came first, and it escalated the decisions that mattered.
• Limit autonomy at irreversible actions. During a code freeze my agent pushed code twice by mistake; today, anything that changes the database comes to me first.