What an Accounting Degree Taught Me About Building Software Companies
I trained as an accountant and became an engineer and founder. The detour wasn’t wasted — it’s my edge. On outcomes, distribution, and finding what’s true.
I have a First Class degree in Accountancy and Business Finance. I spent four years learning how businesses actually make money — and most evenings teaching myself to code. For a long time that looked like a detour. It turned out to be the foundation.
Engineers who understand the business win
Studying finance taught me to reason about systems in terms of outcomes, unit economics, and incentives — not features. When I later cut a cloud bill by 90%, I wasn't thinking like an engineer chasing elegance. I was thinking like someone who'd stared at enough P&L statements to know that cost is a feature.
The best technical decisions I've made were really business decisions in disguise.
The leap to founder
Cochapp was my first company. Going from engineer to founder is going from "solve the problem you're handed" to "find which problem is even worth solving." Three lessons hit hardest:
1. Distribution is as hard as the build
Engineers fall in love with the product. Founders learn — usually painfully — that a great product nobody hears about is indistinguishable from no product. Plan distribution from day one, not after launch.
2. Talk to users before you write the schema
Your data model encodes your assumptions about the world. Encode them after you've checked them against real people, not before.
3. A founder's job is to find what's true, fast
Everything else — code, design, pricing — is downstream of knowing what's real. Treat beliefs as hypotheses. Ship the smallest test. Let reality decide.
Why I build what I build
Today I'm building an AI contact center, CRM integrations, and QA Copilot. The thread connecting them isn't "AI." It's unglamorous, expensive, manual work — exactly the kind of thing a finance brain flags as a margin problem and an engineering brain flags as an automation problem.
That intersection — knowing what's worth automating and how to build it reliably — is the whole game. The accounting degree gave me the first half. The years of shipping gave me the second.
If you're an engineer wondering whether your "irrelevant" background is wasted: it isn't. It's the part of you that will see opportunities the pure specialists walk right past.
Related reading
In Automation, Reliability Is the Product
Browser automation looks like a demo problem and is actually a reliability problem. What building Snappit taught me about why self-healing beats clever.
How I Cut a Cloud Bill by 90% Without Touching Latency
Cost is a feature. Here is the playbook I used to cut a workload’s cloud spend by ~90% while improving p99 — and why most teams leave this money on the table.