A backend engineer and Tech Lead shaped by regulated banking, fintech delivery, and cloud modernization work.
Bruno is strongest in environments where backend depth, architectural judgment, and execution discipline all matter at the same time: payments platforms, modernization programs, regulated systems, and backend teams carrying real operational risk.
Best fit environments
I grew up technically in regulated banking and then spent the last several years in fintech and payments. That combination shaped how I think: correctness first, clear service boundaries, and enough operational visibility that people can trust the system when something goes wrong.
At Itau Unibanco, I worked on backend services, regulatory tooling, and modernization work in a large banking environment. Later, in US fintech roles, I moved deeper into Java and Spring Boot APIs, provider integrations, and the delivery realities of platforms that have to balance speed, compliance, and reliability.
Today I work as a Software Engineering Tech Lead, which means I still care about code and system design, but I also spend time validating architecture, reducing delivery risk, and helping teams move through complex work without losing clarity.
Canadian market positioning
Bruno is targeting senior backend and Tech Lead roles in Canada, especially in fintech, platform engineering, and distributed systems teams where Java, Spring Boot, AWS modernization, and payments depth matter.
The background combines real company history, regulated systems work, cloud modernization, and portfolio projects that stay clearly separated from employer production work.
Three principles shape most of Bruno's engineering decisions.
They show up in architecture reviews, service design, modernization work, and the way operational reality is folded back into engineering choices.
Make the system explain itself
If support, finance, and engineers cannot reconstruct what happened, the design is incomplete. Good backend work makes state, failure paths, and ownership easier to understand.
Tie architecture to delivery
Design only becomes valuable when it helps a team execute. I like architecture that shortens ambiguity, improves rollout safety, and gives people clearer decision boundaries.
Be pragmatic about modernization
Moving from legacy or on-prem patterns to cloud platforms is rarely a clean rewrite story. The real work is sequencing change safely while still improving the platform underneath.
Backend depth, AWS platform familiarity, and financial-systems thinking in one profile.
The value is the combination: strong implementation skill, cloud-aware delivery, and enough architectural range to work comfortably in systems where mistakes are expensive.
Payments and financial backends
Java and Spring Boot services for regulated environments, provider integrations, financial reporting, transaction flows, and correctness-sensitive APIs.
AWS and platform execution
Comfortable with AWS, CloudFormation, CodePipeline, Kubernetes, Docker, OpenShift, and the operational details that determine whether a service is genuinely production-ready.
Technical leadership in delivery
Strong in design review, risk identification, execution discipline, and helping teams make architecture decisions that hold up under deadline pressure.
Leadership here means helping teams make better technical decisions and deliver them cleanly.
The emphasis is on clarity, risk reduction, and execution quality rather than status language or process for its own sake.
My leadership style is practical. I like design reviews that actually help, trade-off conversations that stay concrete, and technical direction that reduces churn for the team.
That means validating architecture against delivery reality, being a senior escalation point when complexity spikes, and keeping the system understandable enough that engineers can move without guessing.
I care about reliability and maintainability, but I also care about pace. The best backend leadership balances technical quality with momentum.