What I Actually Learned Leaving the Bank
Five years inside TD and DBS, and the trade-offs nobody warns you about.
Independent work isn't 'more freedom' the way Twitter sells it. It's a different kind of constraint. Here's what shifted when I left a global bank to build my own studio.
Two years inside TD Bank, two and a half at DBS before that. People ask why I left, and I owe them a more honest answer than the LinkedIn version.
The honest answer is that the work I was doing - refactoring monoliths into Spring Boot 3.2, instrumenting Kafka pipelines, retrofitting Java 17 into legacy services - was excellent training, but the cycle time was incompatible with how I wanted to think.
The constraint nobody tells you about
In a regulated bank, every architectural decision is a six-month negotiation. That's not bad - it's actually how you should treat money. PCI-DSS, SOC 2, internal change-advisory boards exist because failure modes are real. The cost is cognitive: you spend more time aligning than building.
I started keeping a diary of what I was doing each day. After three months I tallied it: about 35% writing code, 40% in meetings or comments aligning the code I'd write next, 15% on compliance paperwork, 10% on actual production support. The compounding rate of personal learning at 35% utilization is much lower than it feels.
The seductive lie of "more time to code"
Going independent does NOT give you more time to code. You replace alignment meetings with sales calls, scoping calls, invoicing, contract review, and (the killer) the cognitive overhead of running yourself as a business.
What it does give you is shorter feedback loops. When I architect something for a fintech founder on Tuesday, it's shipping by Friday. That compression - even if I'm coding less than I did at TD - is where compounding happens.
What banking taught me that nobody else has
- Idempotency is non-negotiable. Every webhook handler, every retry, every Kafka consumer. If you can't replay it safely, it's not done.
- Observability is a deliverable. I now make traces and dashboards a Phase 1 deliverable on every engagement. It used to feel like overhead. Now I think of it as the seatbelts.
- Audit trails outlive your code. Whatever logging schema you commit to, you'll be reading those logs in five years. Pick names you won't regret.
- "Boring" tech doesn't mean unambitious. Postgres, Spring Boot, AWS - these scale absurdly. The novelty is in the architecture, not the dependencies.
What I had to unlearn
The bank taught me to write defensively to the point of paranoia. Three layers of input validation, multiple try/catch nests, every service double-checking the previous service's work. That's appropriate when one bad request can clear regulatory hell. It's actively harmful in a Series A startup that needs to ship 10 features in a month.
The first month working with my own clients, I cut my own validation by 70% and shipped twice as fast - and quality didn't drop, because I'd transferred the rigour to the test layer, not the runtime layer.
What I'd tell my past self
If you're considering going independent: don't romanticize it. Treat it as a different shape of constraint, not the absence of constraint. The skills that earn you a senior staff title at a bank are not the skills that win you your first three clients.
The first will pay your bills if you're patient. The second will pay you well if you keep going.