TRABALHO SELECIONADO

Estudos de caso, não cards de projeto.

Contexto, restrições, decisões e tradeoffs por trás das plataformas que construí e liderei - mantidos qualitativos onde os detalhes de implementação são confidenciais.

Comércio digital corporativo

Plataformas operando em escala nacional

Multi-tenantCheckoutPagamentosFidelidadeCloud-native

Contexto: Uma plataforma de comércio digital multi-tenant que atende mais de 50 marcas de restaurantes nos EUA e milhares de unidades físicas.
Restrição: Cada marca precisa de identidade e configuração independentes, compartilhando um núcleo de plataforma comum, sem duplicar lógica por tenant.
Decisão: Investir em uma arquitetura multi-tenant compartilhada e orientada a configuração, em vez de forks por marca.
Arquitetura: Serviços cloud-native e serverless para checkout, pagamentos, autenticação e fidelidade, sobre uma camada de configuração e feature flags por tenant, integrados a ecossistemas de engajamento como Olo, Thanx, Spendgo, Sparkfly, Braze e Klaviyo.
Tradeoffs: A arquitetura compartilhada aumenta o custo de coordenação para solicitações específicas de marca, mas evita fragmentação e manutenção duplicada em dezenas de bases de código.
Resultado: Uma plataforma em que o trabalho de suporte operacional cresce de forma sublinear em relação ao número de marcas incorporadas.
O que aprendi: Multi-tenancy é uma disciplina aplicada em todas as camadas, não uma única decisão de infraestrutura.

Acessibilidade como prática de engenharia

Acessibilidade antes do QA

WCAGDesign SystemsTecladoHand TalkEqualWeb

Contexto: Os portais institucionais Bradesco / Bradesco Seguros precisavam atender expectativas de acessibilidade para um público amplo.
Restrição: Padrões de marcação legados e ferramentas automatizadas limitadas dificultavam aplicar acessibilidade de forma sistêmica.
Decisão: Tratar acessibilidade como uma questão de componente e de fluxo de trabalho, não como uma etapa tardia de QA.
Arquitetura: Fundações em HTML semântico, um Design System compartilhado, padrões de navegação por teclado, estados de foco visíveis e integrações como o Hand Talk para suporte em língua de sinais.
Tradeoffs: Retroaplicar acessibilidade em componentes existentes levou mais tempo do que construí-la desde o início.
Resultado: Melhorias mensuráveis em operabilidade por teclado, legibilidade e contraste nas experiências institucionais.
O que aprendi: Trazer acessibilidade para mais cedo no fluxo de trabalho é mais barato do que corrigi-la depois - a premissa por trás dos meus artigos sobre o tema.

Observabilidade & confiabilidade em produção

Confiabilidade é uma propriedade projetada

BugSnagLogglyResposta a incidentesGovernança de release

Contexto: Operações de comércio digital de alto volume exigem detecção e resolução rápidas de problemas em produção entre muitos tenants.
Restrição: Incidentes em um sistema multi-tenant podem afetar silenciosamente um subconjunto de marcas, sem sinais globais óbvios.
Decisão: Construir hábitos e ferramentas em torno de observabilidade e investigação estruturada de incidentes, em vez de apagar incêndios reativamente.
Arquitetura: Pipelines de rastreamento de erros e logs (BugSnag, Loggly) alimentando fluxos de investigação, junto de governança de release e revisão de prontidão para produção.
Tradeoffs: A infraestrutura de observabilidade tem um custo inicial que compete com a velocidade de entrega de funcionalidades, mas reduz o raio de impacto e a duração dos incidentes ao longo do tempo.
Resultado: Identificação mais rápida da causa raiz e deployments em produção mais confiantes e bem governados.
O que aprendi: Confiabilidade é uma propriedade projetada de um sistema, não um subproduto de código cuidadoso.

Fluxos bancários & fintech

Correção acima de reutilização

PIXBoletosPagamentos em loteVue / Nuxt

Contexto: Os produtos bancários e financeiros da K8 Fintech precisavam de jornadas de onboarding, gestão de contas e pagamentos construídas com expectativas rígidas de correção.
Restrição: Fluxos financeiros como PIX, boletos, transferências e pagamentos em lote toleram pouca ambiguidade ou falha silenciosa.
Decisão: Priorizar tratamento explícito de estado e feedback claro ao usuário em vez de componentes genéricos reutilizáveis a qualquer custo.
Arquitetura: Jornadas de front-end em Vue/Nuxt integradas a sistemas bancários e de back-office de antecipação de recebíveis.
Tradeoffs: Componentes específicos do domínio eram menos reutilizáveis em todo o produto, mas geraram fluxos financeiros mais claros e seguros.
Resultado: Experiências confiáveis de onboarding, transferência e pagamento em lote em sistemas bancários e adjacentes a RH.
O que aprendi: Em domínios regulados, correção e clareza superam a reutilização de componentes.

Modernização de plataforma

Modernizando um sistema que não pode parar

E-commerceCRMLogísticaPerformance

Contexto: Os sistemas de e-commerce, CRM e logística da Atual Card do Brasil haviam acumulado anos de mudanças incrementais.
Restrição: O negócio precisava de operação contínua enquanto a plataforma evoluía - uma reescrita completa não era viável.
Decisão: Modernizar de forma incremental, priorizando performance e as áreas de maior impacto operacional.
Arquitetura: Otimização de performance, ferramentas de campanha e melhorias de mobilidade adicionadas sobre os sistemas existentes de e-commerce, CRM e logística.
Tradeoffs: A modernização incremental é mais lenta para mostrar resultados dramáticos de antes/depois, mas mantém o negócio funcionando sem interrupções.
Resultado: Ganhos mensuráveis de performance e uma plataforma que continuou evoluindo sem uma reescrita completa e custosa.
O que aprendi: Modernização sustentável respeita a restrição de um sistema que não pode parar de funcionar.

Liderança técnica & governança

Decisões repetíveis, não heroísmo

Tech LeadMentoriaGovernança de release

Contexto: Como Tech Lead, o crescimento da plataforma exigiu uma tomada de decisão técnica mais estruturada do que revisões pontuais.
Restrição: Equilibrar velocidade de entrega com qualidade de código, necessidades de mentoria e risco de produção em uma equipe em crescimento.
Decisão: Estabelecer direcionamento técnico claro, padrões de code review e critérios de prontidão para produção, em vez de decisões caso a caso.
Arquitetura: Revisões de arquitetura, práticas de mentoria e um processo de governança de release que inclui autoridade para aprovar PRs e deployments em produção.
Tradeoffs: A governança formal adiciona atrito à autonomia individual, mas reduz a variância de risco em produção em uma plataforma em crescimento.
Resultado: Releases mais previsíveis e um caminho mais claro para outros engenheiros assumirem responsabilidade.
O que aprendi: Liderança técnica é, na maior parte, construir tomada de decisão repetível, não tomar cada decisão pessoalmente.

Marcas selecionadas atendidas

Uma amostra representativa de marcas de restaurantes nacionais e regionais que operam nas plataformas de comércio em que trabalho na Plein Air Agency. Listadas para transparência sobre a escala do trabalho - a inclusão aqui não implica endosso dessas empresas.

goop KitchenLee's Famous RecipeBojanglesLong John Silver'sJason's DeliDig InnCiCisNewk'sTex'sDiBella'sTaco PalenqueCosta VidaCotton PatchNeighborlyTatteO'Charley'sFlame BroilerTijuana FlatsBaja FreshCold Stone CreameryPlanet SmoothieSweet FrogTacoTimeWetzel's PretzelsRusty TacoNekterCaptain D'sFlying PieGolden ChickHello HiloChicken Salad ChickDave's Hot ChickenMellow MushroomTaco Time NWPoke HouseNayaFlanigan'sDirty DoughGenghis GrillBiBiBopBud Long'sCharleysLenny'sWing It On99 RestaurantsAltitudebartacoBoard & BrewFresh BrothersHomeward KitchenJim 'N Nick'sKrispy Krunchy ChickenMain EventRazzoo'sSbarroPuraLimaRapid Fired PizzaSonny's BBQWhataburger