Em apenas quatro meses, uma jornada ambiciosa do conceito à realidade se desenrolou quando embarcamos na criação de uma solução única de cartão de débito. Este é o artigo que gostaríamos de ler!
Sou Daniel Ishigami, desenvolvedor e empreendedor autodidata radicado em Londres e cofundador da Fana. Juntamente com o meu parceiro Robin Yan, lançámos um cartão de débito que transforma os gastos diários num ato de filantropia. A Fana foi fundada para mudar a forma como as pessoas contribuem para causas que lhes interessam, permitindo o impacto através de compras regulares, permitindo assim que indivíduos, criadores e marcas aloquem fundos para causas significativas.
Já te incomodou ser solicitado a doar para potes de arrecadação ou concordar com rondas por causas com as quais você não se identifica quando está gastando dinheiro?
Fundamos a Fana porque vivemos em uma geração obcecada por impacto positivo. As gerações Y, Z e A são, coletivamente, o maior grupo demográfico de consumo em crescimento e seus gastos representam 60% das vendas online. A experiência de caridade e doação atualmente simplesmente não corresponde a essa intenção de gasto, nem a esse padrão. Queríamos criar um cartão real no qual os consumidores pudessem se inscrever e pagar, permitindo-lhes posteriormente doar para uma instituição de caridade Fana no aplicativo e comprar em uma marca que devolvesse recompensas de doação ao usuário para criar mais impacto.
Este artigo é um mergulho profundo nas complexidades do desenvolvimento de um cartão de débito do zero, cobrindo tudo, desde a fase de conceito inicial até o lançamento final. Compartilharemos informações valiosas sobre nosso processo de seleção, estrutura de avaliação e decisões estratégicas que abriram caminho para nosso sucesso. Você terá uma visão exclusiva do nosso ciclo de desenvolvimento, incluindo os desafios que enfrentamos e como os superamos, oferecendo um guia completo para quem deseja embarcar em uma jornada semelhante.
A visão por detrás deste ambicioso projecto era colmatar uma lacuna no mercado que eu, tanto como consumidor como como doador, tinha experimentado pessoalmente. Existe uma vasta comunidade de indivíduos ansiosos por apoiar causas significativas e causar um impacto positivo, mas muitas vezes ficam perdidos, dissuadidos por processos de doação desatualizados que culminam em reconhecimentos insatisfatórios. Da mesma forma, inúmeras marcas aspiram contribuir para o bem da sociedade, mas estes esforços louváveis passam frequentemente despercebidos, enterrados nas notas de rodapé dos relatórios anuais de sustentabilidade. Nosso objetivo era ser pioneiro na primeira fase de uma plataforma que unisse perfeitamente consumidores e marcas em sua busca por fazer a diferença.
Junte-se a nós enquanto desvendamos as camadas do nosso processo de desenvolvimento, compartilhamos as ferramentas e tecnologias que tornaram tudo isso possível e discutimos as lições aprendidas ao longo do caminho. Quer você seja um empreendedor iniciante, um desenvolvedor experiente ou simplesmente curioso sobre a inovação em fintech, este artigo transporta você pela jornada até a criação de um cartão de débito.
O processo de triagem: um quebra-cabeça de 100 peças Navegando pelo cenário complexo do ecossistema financeiro integrado, embarcamos em nossa jornada começando do zero em um campo povoado por quase uma centena de fornecedores, muitos dos quais especializados em executar apenas uma única tarefa crítica para o operação de um cartão de débito. A falta de informação publicamente disponível não nos deteve; em vez disso, começamos do zero, entrando em contato e discutindo com diferentes participantes do ecossistema com os quais poderíamos nos conectar (os grupos do Slack são seus amigos). Estas conversas iniciais desmistificaram gradualmente as complexidades das finanças incorporadas, revelando os componentes essenciais necessários para dar vida à nossa visão:
Para aqueles interessados em se aprofundar no espectro de emissores e em suas capacidades, uma visão geral abrangente está disponível aqui ( https://docsend.com/view/uia26zpnucyvgxqa ).
Nossa avaliação para selecionar o parceiro certo se concentrou em:
Capacidade de atuar como uma solução pronta para uso para os componentes acima. Como a integração de 3 ou 4 provedores para os itens acima aumentará a sobrecarga e o tempo de lançamento no mercado, faz sentido optar inicialmente por um fornecedor, mesmo que isso remova algum controle sobre os componentes.
Transparência de sua documentação técnica e disponibilidade de um sandbox (“experimente antes de comprar”) que foi vital para testar e experimentar a integração, visto que agora construiríamos uma peça central de nosso produto com base em sua API.
Relação custo-benefício e escalabilidade que determinamos por meio de custos modelados ao longo de um período de 3 a 5 anos para uma variedade de cenários comerciais. Era imperativo que o parceiro escolhido não só oferecesse preços competitivos, mas também um modelo de preços que apoiasse o escalonamento – capaz de se adaptar ao nosso crescimento e aos diferentes volumes operacionais.
Por fim, chegamos ao weavr https://www.weavr.io/, pois eles atendiam a todos os critérios acima. Eles ofereceram toda a cadeia de suprimentos para entregar nosso produto de cartão, entenderam e puderam se mover no ritmo de uma startup, tinham um sandbox que nos permitiu testar suficientemente e ganhar confiança na capacidade de integração com sua API e por último tinham um modelo comercial que permitido para dimensionamento.
Planejamento: uma meta sem plano é apenas um desejo
Paralelamente ao processo acima, criamos um mapa de recursos e um conjunto de histórias de usuários que serviram de base para quais funcionalidades precisávamos construir.
Isto também poderia ser usado como base de discussão com partes interessadas comerciais, bem como designers e desenvolvedores (miro é uma ferramenta fantástica para isso https://miro.com/templates/ ). Seguindo um acordo sobre o acima exposto, tivemos que definir o escopo das sequências de API em um diagrama para todas as funções, como criação de um usuário, criação de uma conta e um cartão. Depois que essa sequência foi configurada, ela foi testada no postman (uma ferramenta de teste de API) por meio de uma coleção útil que foi disponibilizada. Neste processo, quaisquer erros já podem ser resolvidos antes do processo de construção. Paralelamente aos testes, um resumo do mapa de recursos e histórias de usuários junto com a sequência que tivemos que seguir para chamadas de API foi discutido com nosso designer e ele construiu uma versão demo no Figma que poderia ser testada inicialmente pela equipe. Isso incluiu, antes da implementação, um teste A/B que poderia ser realizado nos usuários - a aprovação/reprovação foi determinada pela taxa de conclusão e revisão via typeform que vinculamos no final das telas de demonstração.
Enquanto o trabalho acima estava sendo realizado pelo lado do desenvolvedor, decidimos começar com uma versão web que nos permitiria iterar mais rapidamente, uma vez que a distribuição através dos mercados da Apple e do Google está frequentemente sujeita a vários processos de revisão que podem facilmente adicionar mais de 1 mês a um cronograma de publicação . Sentimos que seria melhor entregar o mais rápido possível e iterar antes de nos comprometermos com um lançamento móvel.
Execução: Executar, Executar, Executar Para entregar o produto final configuramos nossa infraestrutura da seguinte forma:
Nosso serviço instantâneo de back-end está usando Java Spring Boot, uma escolha impulsionada pelo ecossistema robusto, facilidade de desenvolvimento e eficiência de desempenho do Spring Boot (centenas de dependências úteis disponíveis imediatamente por meio do inicializador Spring https://start.spring.io/ ) . Este microsserviço é a espinha dorsal da nossa aplicação, lidando com todas as ações imediatas e orientadas por eventos que são críticas para uma experiência de usuário perfeita (por exemplo, inscrição, login, gerenciamento de sessão, todas as operações de cartão). Embora empreguemos aspectos do padrão de design Model-View-Controller (MVC), com foco específico em modelos e controladores, nossa arquitetura é projetada principalmente para a construção de serviços de API. Essa abordagem nos permite separar efetivamente nossa lógica de negócios e processos de tratamento de solicitações, garantindo uma organização de código limpa e sustentável.
Este é o serviço que integra várias APIs externas e, mais importante ainda, aquelas do nosso provedor financeiro integrado, bem como outros componentes críticos, como Stripe para faturamento e Sendgrid para notificações instantâneas.
Nosso Agendador de Tarefas Distribuídas de Backend é um serviço projetado para gerenciar tarefas periódicas. Este componente desempenha um papel fundamental na garantia da fiabilidade e oportunidade das operações em segundo plano, desde notificações, reconciliação contabilística e financeira, bem como, quando necessário, pesquisa de dados de fornecedores externos. Ele oferece suporte a vários tipos de gatilhos, incluindo gatilhos cron, manuais e baseados em eventos, proporcionando flexibilidade em como e quando as tarefas são executadas.
O Front End do nosso aplicativo web é construído com React, com foco em ser amigável ao usuário móvel. Na medida do possível, usamos componentes prontos para uso que ficam ótimos tanto em desktops quanto em dispositivos móveis, para que pudéssemos reduzir a necessidade de animações personalizadas e ter capacidade de resposta pronta para uso.
Para monitoramento e observabilidade em nosso sistema, integramos o Spring Boot com uma biblioteca projetada especificamente para expor métricas do Prometheus (Prometheus é um kit de ferramentas de monitoramento e alerta de sistemas de código aberto originalmente construído no SoundCloud), que são então consumidas pelo Grafana para monitoramento e fins de visualização. Essa configuração, conectada a uma réplica somente leitura de nosso banco de dados de produção, nos capacita com insights críticos necessários para rastrear erros e bugs na produção, comportamento do usuário e coisas que podem não funcionar tão bem quanto pretendido, e rastreamento de conversão/funil. Ele nos permite criar e visualizar consultas adicionais sob demanda. Juntamente com o Google Analytics, esta abordagem oferece uma visão abrangente das interações do usuário em cada momento. Além disso, utilizamos os robustos recursos de registro do nosso provedor de serviços em nuvem para rastreamento detalhado de erros.
Para gerenciar nosso sistema de nomes de domínio (DNS), que é vital para configurar diversos clientes de serviços, desde plataformas de email marketing até ferramentas analíticas, contamos com a Cloudflare. A Cloudflare não serve apenas como nosso sistema de gerenciamento de DNS, mas também funciona como nossa principal rede de entrega de conteúdo (CDN). Este duplo papel é crucial para a nossa operação, pois garante que os nossos ativos digitais, incluindo imagens e ficheiros de vídeo, sejam armazenados e distribuídos de forma eficiente em todo o mundo. A utilização da Cloudflare melhora o desempenho e a segurança do nosso site, oferecendo tempos de carregamento rápidos e proteção robusta contra ameaças cibernéticas. Esta configuração é fundamental para manter o acesso contínuo ao nosso conteúdo, facilitando uma experiência de usuário ideal e protegendo os dados do usuário, apoiando assim a nossa estratégia on-line abrangente.
Conclusão Para nossas estratégias de marketing, principalmente quando se trata de testes A/B para otimizar a geração de tráfego e avaliar a eficácia de diversas campanhas, escolhemos o Webflow como nossa principal ferramenta para projetar e desenvolver nossas páginas de destino e marketing. Essa plataforma nos permitiu iterar rapidamente o design e o conteúdo, permitindo ajustes em tempo real com base nos resultados dos testes. A interface amigável e os recursos poderosos do Webflow apoiaram nossa equipe na criação de páginas visualmente atraentes e de alto desempenho, essenciais para envolver nosso público-alvo e impulsionar nossos objetivos de marketing.
Ao concluirmos nossa jornada desde o conceito até o lançamento de nossa solução exclusiva de cartão de débito, fica evidente que o caminho foi desafiador e gratificante. Ao longo destes meses, navegamos pelas complexidades do ecossistema fintech, interagimos com uma infinidade de fornecedores e reunimos os componentes necessários para dar vida à nossa visão. Esperamos que os insights compartilhados neste artigo, desde o processo de triagem inicial até a implantação estratégica de tecnologias como Java Spring Boot, React e Cloudflare, ajudem qualquer pessoa que queira incorporar serviços financeiros e reduzir alguns dos obstáculos que encontramos ao longo do caminho.
Refletindo sobre a nossa jornada, a principal conclusão é que criar uma solução fintech como a nossa é mais do que apenas um empreendimento técnico; é um esforço orientado pela missão para melhorar a forma como contribuímos para a sociedade através das transações diárias. À medida que avançamos, estamos entusiasmados em construir sobre esta base, melhorar continuamente a nossa oferta e expandir o impacto do nosso trabalho.
Saiba mais sobre Fana: https://www.fanaverse.io/