Background
About
Who you would actually be working with, how I approach a system, and why a team can trust the answer.
I started in Electrical Engineering and moved deep into software, but the engineering mindset stayed the same: understand the system, find the constraint, fix the underlying problem.
The move into software was gradual and then total. What pulled me in was not the language or the framework but the same thing electrical engineering had already taught me to like: systems with enough moving parts that you cannot hold them all in your head at once, where the interesting work is figuring out which part actually matters.
That preference decided the kind of work I ended up doing. I gravitate to the problems most people avoid, which in practice means backend architecture and integrations: distributed state, third-party APIs that behave differently from their documentation, schema decisions that have to survive real load, and the class of production failure where every dashboard is green and the system is still wrong.
Today that work happens across SaaS platforms, e-commerce systems, cloud infrastructure and product engineering, mostly for North American clients through Arctic Leaf. The common thread is systems that have accumulated enough complexity that the obvious solution stopped being the right one.
Outside client work I build and publish my own systems software, largely in Rust and Go: a fixed-income library on crates.io, a multiprotocol API client, a serverless email service. They exist because I wanted them to, and they are also the clearest evidence of how I make technical decisions when nobody is constraining them.
B.Eng. Electrical Engineering — CEFET-RJ, Brazil.
How I work
Working principlesFind the constraint first
No rewrite proposal before the actual bottleneck is identified. The obvious suspect and the real cause are different often enough to be worth the time.
Write decisions down
Architecture that only exists in a meeting does not survive the meeting. Decisions come with the reasoning, so the next person can tell whether it still holds.
Prefer boring reliability over cleverness
Complexity is worth it when the problem demands it and expensive when it does not. Most systems in trouble got there one clever shortcut at a time.
Work with the existing team
Consulting should raise the leverage of the engineers already there, not build a parallel organization that leaves with me.
Technical range
What I work in- Core
- TypeScript · Node.js · Rust · Go · PostgreSQL
- Cloud
- AWS · Cloudflare
- Architecture
- APIs · event-driven systems · serverless · multi-tenancy · auth & sessions · integrations
- Commerce
- Shopify · BigCommerce · Miva · ReCharge · HubSpot
Selected experience
Where the work happenedBackend architecture, SaaS, e-commerce systems, integrations, AWS and Cloudflare infrastructure, and client delivery.
Selected engagements SmartBrokr · Mistobox · Pacbrake × Xorosoft · Organo Gold · Clint Pharmaceuticals · Transcendent Travel · Mountain Crest & Right Rope · Arctic Teamwork CLI (al) · One Party Rental
Selected web, mobile and integration work.
Selected engagements Kosher
Continued selected client work independently after Daydream's handoff.
Mobile and web product engineering across Ionic/Angular, Python integrations, and backend services.
Selected engagements Kosher · Infiniscope
Independent engineering
Unconstrained decisionsClient work always carries constraints that are somebody else's: an existing schema, a delivery date, a platform already chosen. What I build on my own time has none of that, which makes it the clearest evidence of how I decide when nothing is forcing my hand.
- protoglot Multiprotocol API Client
- yield-curves Rust Yield Curve Library
- Ephemask Disposable Email Service