There’s a specific kind of humility that hits you when a client asks “how are you handling rebalancing logic?” and you realize you understood every word of that sentence except what it means.
Zypher Assets is an investment platform, and going in, I thought I knew fintech — I’d shipped payment systems, receipt pipelines, transaction logic. Turns out “moving money correctly” and “modeling an investment portfolio correctly” are cousins, not siblings. I had to actually go learn what I was building.
What I didn’t know that I needed to
Portfolio allocation math. The difference between realized and unrealized gains, and why that distinction has to be correct in the data model from day one or every report downstream lies to someone. Compliance language around what a platform is and isn’t allowed to imply about returns. None of this is exotic to a finance person. All of it was new to me, and getting it wrong wasn’t a UI bug — it was a “someone makes a bad financial decision based on my code” bug.
How that changed how I build
I stopped treating domain research as a nice-to-have that happens in a discovery call and started treating it as an engineering deliverable. Before writing the schema for holdings and transactions, I spent real hours with finance documentation and existing platforms, taking notes like I was back in a Babcock lecture hall. Slower start. Fewer expensive misunderstandings six weeks in.
The principle I carry now
Every domain a client operates in — healthcare, fintech, education — has an expert somewhere who would wince at what a purely technical read of the requirements produces. My job isn’t just to write correct code. It’s to actually understand the thing I’m encoding well enough to catch my own blind spots before a user pays for them.
Zypher taught me that lesson expensively enough that I haven’t needed it taught twice.