The problem

I've used a budgeting spreadsheet for over a year. It's a template from Etsy, and it's genuinely good: I can see every account in one place, and project my balance out a full year, paycheck by paycheck. Every app I tried before it got one thing wrong: they'd roll money into the next pay period that wasn't actually going to be there, because they couldn't handle a bill landing on a slightly different date each month.

The spreadsheet solved that. What it can't do is move money. I still open my bank app separately to act on anything it tells me.

Fortify is what happens if you don't accept that gap. The moment you learn something about your money and the moment you can act on it should be the same tap, not two separate apps.

What it does (in progress)

Fortify is designed around a projected balance, not just a current one. It's built for someone I think of as Maya: comfortably ordinary income, no real financial trouble, but she still checks her balance defensively before buying anything non-routine, because she doesn't trust the number to account for what's about to happen. The forecast is designed to be the number she can trust instead.

Under the hood: Plaid for account linking and read access, Dwolla for actually moving money; real ACH transfers, a real balance, instant push-to-card payouts, and Appwrite for auth and data.

Product decisions worth explaining

One persona, not a segmented set

Every feature got checked against a single question: does this reduce Maya's mental math? If not, it's not v1. This kept scope honest in a project with no PM to say no for me.

A phased, stack-aware roadmap

Dwolla can't do everything I originally scoped; no currency exchange, and card-based top-ups need a second provider. Rather than quietly building a worse version of those features, I named the real providers each one would need in production, and drew a clear line between what the current stack genuinely supports and what stays documented.

A recurring-payment model borrowed from something that already worked

The forecasting feature is the hardest part of this project, and I didn't start from a blank page. My own spreadsheet already solved it: a recurring rule (name, frequency, amount, start date, end date) plus per-occurrence exceptions for the one month a bill lands on a weird date. I designed Fortify's data model around that pattern instead of trying to auto-detect recurring transactions from raw history, a harder and less reliable problem than it looks.