What 25 Years of Fortune 100 Finance Taught Me About Building Software

Let me start with a confession: I have zero formal training in software development. None. Nada. My background is 25 years of FP&A at Fortune 100 companies across six industries. I'm the guy who built the budget models, challenged the revenue forecasts, and told the VP of Marketing why their plan didn't pencil out. Not exactly the profile you'd put on a "Meet Our Engineering Team" page.

And yet here I am, with a production SaaS platform running Stripe billing, Supabase authentication, 118 automated tests, real-time error monitoring, and an AI solver that helps kids learn math. It handles real payments from real families. It doesn't crash. The tests pass. The monitoring is green.

How? Well, that's the interesting part.

AI didn't teach me to code. It let me skip the part I didn't need.

Here's what nobody tells you about building software with AI tools: the hard part was never the syntax. It was never remembering whether JavaScript uses curly braces or semicolons (it's both, which is exactly the kind of design decision that makes you question the entire field).

The hard part is knowing what to build and why it matters. Which database table structure supports the business model you'll want in 18 months. Which billing edge cases will cost you customers if you don't handle them now. Why your authentication flow needs to think about COPPA compliance before you have your first child user, not after.

Those aren't coding problems. They're business problems. And after 25 years of managing P&Ls, analyzing cost structures, and building financial models for companies with billions in revenue, I'm pretty good at business problems.

AI handles the translation from "here's the business logic I need" to "here's the code that implements it." I handle the part where you figure out what the business logic should be in the first place. Turns out that second part is way harder — and way more valuable.

The "vibe coding" crowd gives this a bad name

Look, I'm going to be a little direct here. There's a growing army of people who type a prompt into an AI tool, accept whatever code comes back, and call themselves developers. Some of them are building genuinely impressive demos. Emphasis on the word "demos."

A demo doesn't have to handle what happens when a credit card expires mid-subscription. A demo doesn't need row-level security policies on every database table. A demo doesn't need to gracefully recover when the AI API goes down at 2 AM on a Saturday. A demo just needs to look good in a screen recording.

Production software needs to survive contact with actual humans. And actual humans are wildly creative at finding ways to break things you never imagined. My approach isn't "generate code and hope." It's "generate code, review it line by line, test it against every edge case I can think of, monitor it in production, and fix what breaks before users notice." That's not AI magic. That's the same discipline I applied to financial reporting for two decades — you verify the numbers before they go to the board.

The business person's unfair advantage

Here's the part that genuinely surprised me: my FP&A background isn't a limitation in software development. It's a superpower.

When I design a database schema, I'm thinking about what financial reports the business will need in six months. When I build a billing system, I'm thinking about how pricing changes affect customer lifetime value. When I architect a feature, I'm thinking about whether it drives retention or just looks good in a product demo.

Most developers build what the spec says. I question the spec first. "Sure, we could build that feature — but based on the unit economics, it'll cost $3 per user per month to operate and it'll be used by maybe 8% of your customers. Want to rethink that?"

That conversation never happens at an agency. It happens in every project I touch, because I spent 25 years learning to think that way. You can teach someone to code. You can't fast-track the instinct to see business implications in technical decisions. That takes time in the chair.

The speed is almost unfair

Here's what makes my wife suspicious that I'm not actually working: projects that used to take a team of five developers three months now take me a few weeks. Same quality. Same infrastructure. Same testing rigor. Just fewer humans doing things that don't require humans anymore.

No sprint planning meetings. No morning standups where eight people take turns saying "no blockers." No Jira tickets. No waiting for the frontend team to unblock the backend team. When I see a problem, I fix it. When I see an opportunity, I build it. The feedback loop between "good idea" and "working software" is measured in hours, not quarters.

That speed isn't because I cut corners. It's because I eliminated the coordination overhead that adds zero value to the finished product. The software doesn't care whether three people had a meeting about it before it got written.

What this actually means for business owners

If you're a business owner with an idea for a software product, the economics have fundamentally changed. You don't need $150K and a 6-month timeline. You don't need to manage a team of people who don't understand your business. You don't need to translate your vision through three layers of project managers who dilute it at every handoff.

You need someone who understands your business problem deeply enough to build the right solution — and has the tools to do it without the overhead that made software development expensive in the first place.

That's what I do. It's a weird combination, I know. Finance guy builds software. But weird combinations are usually where the interesting opportunities are. The best sushi I've ever had was at a gas station in Carlsbad, and the best software builder you'll find might be a finance guy who got tired of approving budgets for other people's code.