Crypto para Novos Tipos de Conta

Contexto

O grupo Merchant Engineering do PayPal conduz iniciativas para expandir capacidades de crypto para mais partes do ecossistema de contas. Trabalhei no lado de crypto desse portfólio. O objetivo do frontend era mais específico do que “construir trading de crypto” — o fluxo de compra, venda e transferência já existia e funcionava. O trabalho era estender esse mesmo fluxo para que um tipo específico de conta, antes excluído, também pudesse usá-lo sem bifurcar a experiência em uma implementação paralela.

Essa distinção definiu tudo que veio depois. O risco real não estava na lógica de crypto, mas em cada lugar onde o fluxo existente assumia silenciosamente os tipos de conta que já suportava, distribuídos por superfícies de responsabilidade de vários times. Lacunas de integração entre essas superfícies, e não as mudanças de código em si, eram o que bloqueava a adoção. Liderei a habilitação do frontend e atuei como principal ponto técnico de contato nas investigações entre times que vieram junto.

Os sistemas envolvidos são confidenciais, então este case descreve a forma do trabalho, não os detalhes internos — incluindo qual era o tipo de conta.

Decisões

Validar no nível da jornada, não do componente. O modo de falha não vivia dentro de um componente isolado — estava entre superfícies, nos lugares em que o fluxo existente assumia um tipo de conta para o qual nunca havia sido estendido. Em vez de depender de cobertura unitária, construí e validei as jornadas de compra, venda e transferência de ponta a ponta, especificamente como o tipo de conta recém-habilitado, por meio de testes E2E extensos. A troca é real: suítes E2E rodam mais devagar e custam mais para manter. Mas testes unitários não enxergam uma lacuna de integração; apenas percorrer a jornada completa — como o tipo de conta para o qual ela não foi criada — revela onde ela quebra numa fronteira de time. As execuções E2E se tornaram o instrumento para encontrar essas quebras.

Registrar as lacunas. Quando os testes encontravam uma lacuna de integração, a saída barata seria abrir um ticket e seguir codando. Escolhi escrever documentação de análise de lacunas: o que estava quebrado, qual time era responsável e o que aquilo bloqueava adiante. Documentação é tempo não gasto em código e ela envelhece. Mas, numa iniciativa com vários times, a restrição não é throughput de código; é visibilidade compartilhada. A documentação melhorou a clareza sobre entregáveis entre times e acelerou a decisão de rollout, que era o gargalo relevante.

Um ponto de contato em vez de coordenação por broadcast. As investigações entre times passavam por mim como principal contato técnico. O risco óbvio é serializar tudo: uma pessoa vira a fila. O ganho é que dependências de plataforma foram traduzidas uma vez, de forma consistente, em escopo de engenharia acionável, em vez de cada time reconstruir o contexto do zero. Mantive a função como tradução, não como bloqueio: a saída sempre era trabalho delimitado que outro time poderia assumir sem depender de mim na sala.

Impacto

As mudanças de frontend estenderam o fluxo existente de compra, venda e transferência de crypto do PayPal ao tipo de conta que ele havia excluído até então — o objetivo central da iniciativa. As jornadas validadas em E2E deram aos times envolvidos uma definição concreta e compartilhada de “funcionando” para aquela conta, algo mais difícil do que parece quando o fluxo cruza várias fronteiras de responsabilidade e nunca foi criado para esse caso. As lacunas encontradas nos testes — lugares onde o fluxo ainda assumia o tipo de conta antigo — foram corrigidas em coordenação com vários times de engenharia em vez de aparecerem mais tarde no rollout. A documentação de análise de lacunas acelerou a decisão de rollout ao dar a quem decidia uma visão precisa do que estava pronto, bloqueado e por quem.

Não há números públicos para associar aqui; o resumo honesto é qualitativo — um tipo de conta antes excluído foi habilitado, uma decisão aconteceu mais rápido e houve menos surpresas nas fronteiras.

Notas de stack

O trabalho no fluxo usa React e TypeScript sobre uma superfície de crypto existente — mudanças incrementais e deliberadas para estender elegibilidade, não uma reescrita. A cobertura de ponta a ponta roda em Cypress, tratando a jornada de compra/venda/transferência como unidade de teste para o tipo de conta que ainda não havia sido validado. Uma parte relevante da entrega foi texto, não código: análise de lacunas e documentação técnica pensadas para leitura de outros times.

Em paralelo, avaliei e pilotei ferramentas de desenvolvimento com IA — Cursor e Claude Code — dentro do time, propondo mudanças de fluxo que melhoraram produtividade e eficiência de entrega.