I'm a developer. I want to be clear about that from the beginning—not because anyone is arguing the point, but because my background makes it easy for people to assume otherwise. In the past, that assumption has cost me more than I'd like to admit.

Before I started writing code professionally, I spent my time in graphic design. Switching careers was a deliberate move; I went through a bootcamp and put in the work to build a real path in software development. To be fair, the design background is a massive asset. I can look at a Figma file and see exactly what the designer intended, and I can talk shop with UI/UX teams without needing a translator. Those are genuine advantages in any frontend role.

The struggle starts when an employer sees both skills on a resume. The math they do is pretty simple: one person, two skillsets, one salary. Before I know it, I'm the "designer who codes." I end up stuck in WYSIWYG editors, pushing pixels, and building prototypes while barely touching the actual codebase. It's frustrating to be sidelined from the architecturally interesting work, and after seeing this pattern repeat, I decided it was time to break it for good.

That's not to say those roles were a waste of time. I picked up essential skills like SEO, accessibility, and web analytics—things that make me a much stronger frontend engineer. I especially value web analytics; being able to actually measure if what I built is working for users is something a lot of devs skip, but it's a core part of my process now. I'm keeping those skills in my toolkit, but I'm done with roles where I'm designing things instead of building them.

Fortify is my way of drawing a line in the sand. A banking app is about as far from a "quick prototype" as you can get. I even made the choice to use an existing Figma template for the UI instead of designing one from scratch. It was a conscious move to keep myself firmly in developer mode and avoid any temptation to drift back into design work. This project is about heavy-duty, real-world engineering, plain and simple.

Why a Banking App

Fintech sits in a different category from most web development. Most applications deal with familiar problems: user accounts, data storage, maybe a payment form. The stack almost writes itself. Banking applications deal with all of that plus real money movement, external services that don't tolerate loose error handling, and an entire layer of financial infrastructure that most developers never have to think about.

That complexity is the point. I'm building toward a career in fintech specifically because the problems are harder, the stakes are higher, and the gap between knowing how to build web apps and understanding how financial infrastructure actually works is wide enough to matter. Fortify is how I close that gap hands-on.

What I Found When I Got Into It

The first surprise was how narrow the realistic options are for developer-accessible financial infrastructure. The services most people recognize — Zelle, Venmo, Cash App — don't offer public APIs. They're consumer products, not developer platforms. Zelle is a payment network owned by a consortium of major US banks, accessible only to licensed financial institutions through a proprietary integration. It was never an option. The actual landscape for a developer building real money movement is smaller and more specific than most people assume.

The second surprise was how cleanly the fintech service layer separates into distinct responsibilities. Bank account linking and payment processing sound like one problem. They're not. Plaid handles the OAuth handshake with financial institutions — account verification, balances, transaction history. Dwolla handles the actual ACH transfers. Neither service does what the other does. Treating them as separate concerns wasn't an architectural preference; it was the only way the integration made sense.

The Stack

Fortify is built on Next.js with the App Router, TypeScript throughout, and Appwrite handling authentication and application data. Plaid connects bank accounts. Dwolla processes transfers. The test layer uses Jest, React Testing Library, and Mock Service Worker — chosen specifically to mock external API calls realistically without hitting live sandboxes.

Each of these decisions has a story. Why Appwrite over Supabase or Firebase? Why Dwolla when Stripe also supports ACH? Why MSW instead of just using jest.mock()? Those are documented in Architecture Decision Records in the repository, and they each get their own post in this series.

What This Series Covers

This is the first in an ongoing series documenting the build:

1. Why I built a banking app (you're here)
2. Choosing the stack — the fintech infrastructure landscape and why each service made the cut
3. Auth with Appwrite — the current implementation and where it falls short
4. Rethinking auth — what I changed and why
5. Bank linking with Plaid — the OAuth flow, what the sandbox hides, what production adds
6. Moving money with Dwolla — the Plaid → Dwolla handoff and the ACH model
7. Testing a fintech app — mocking external APIs realistically with MSW
8. What's next — open questions, roadmap, and what I'd do differently

The repository is public at github.com/eprisr/fortify-banking if you want to follow along with the code.

The gap between building web apps and building financial infrastructure is real, and it doesn't close by reading about it. That's what this series is, a record of working through it.