Abacate Pay
como ajudamos o Abacate Pay a moldar o produto antes do primeiro deploy
A Abacate Pay chegou com tese validada, capital captado e prazo para mostrar produto. O time tinha dois desenvolvedores e nenhum designer. Sem fluxo definido e sem sistema visual, cada semana de código era débito técnico esperando para acontecer. Entramos para dar forma ao produto antes que ele virasse irreversível. Definimos os primeiros conceitos, os fluxos principais e um design system pensado para o time interno estender sem onboarding. Depois do lançamento, eles seguiram voltando: cada redesign passa pelo nosso critério antes de subir.
O ponto de partida
O briefing era específico, não ambicioso. A Abacate precisava de um gateway de pagamentos PIX que indie hackers e times pequenos pudessem integrar em minutos. O posicionamento da empresa estava resolvido. Faltava o produto.
O painel
O painel é onde o desenvolvedor passa o tempo. Lista de pagamentos como tela inicial, não dashboard com cards. Saldo disponível em destaque, número de transações concluídas como segunda informação, filtros (Concluídas, Pendentes, Falhas) ao lado dos botões de ação. A leitura é direta: o que entrou, o que falhou, o que ainda está pendente.
Forma antes do código
Antes de qualquer Figma de alta fidelidade, mapeamos com o time os estados mínimos que um gateway precisa cobrir: cobrança criada, cobrança paga, cobrança expirada, falha de processamento, reembolso, estorno. Quando o estado existe no produto e não existe na tela, vira ticket de suporte. Quando existe na tela mas não no produto, vira frustração silenciosa. A v1 do app foi desenhada com esses estados como esqueleto. As telas vieram depois, ancoradas no estado, não no caminho feliz.
Um design system para um time sem designer
O DS foi pensado para o time interno usar sem ter designer ao lado. O critério de inclusão foi um só: cada componente precisava ser entendível em poucos segundos. Se exigia explicação, ficava fora da v1. Cor, tipografia, espaçamento e estados de input ficaram documentados como tokens nomeados, não como referência visual. O desenvolvedor consome o token, não interpreta o pixel.
A plataforma vista pelo cliente da Abacate
O cliente da Abacate é o desenvolvedor que integra. Pra ele, a plataforma precisa parecer feita por engenheiro: sem ornamento, com hierarquia clara, sem celebrar pequenas conquistas com animação. Cada tela do produto passou por essa régua. Quando a decoração tirava espaço da informação, ela saía.
Eles voltaram
O app foi pra produção e o time interno seguiu construindo o produto. Algumas releases depois, voltaram com uma pergunta: "Temos esse redesign. O que vocês fariam diferente?" O padrão se firmou. A cada redesign relevante, o time prototipa, manda pra gente e usa nosso parecer como referência antes de subir. Consultoria sob demanda, não escopo fechado.
Seu produto pode ser o próximo.
Atendemos founders e times pequenos que precisam de UX, design system e visão de produto antes que cada decisão de código vire débito técnico.