Construindo para aprender: os projetos que estão moldando minha evolução como desenvolvedor

Introdução

Aprender desenvolvimento fica diferente quando a gente transforma uma ideia em um produto que outras pessoas podem usar. Além de fazer uma tela funcionar, é preciso pensar nos dados, nas regras, nos erros, na acessibilidade e em como manter tudo compreensível.

Nos últimos projetos, tenho explorado desafios bem diferentes: transformar dados públicos do GitHub em uma ficha de personagem, registrar e analisar partidas em um app mobile, criar um sistema gamificado de quests e ajudar pessoas a estruturar instruções para ferramentas de IA. Cada um me ensinou algo diferente sobre construir software.

Por que comecei a construir projetos próprios

Projetos próprios me colocam diante de problemas que não vêm com uma solução pronta. Preciso escolher o que faz parte do produto, definir como as informações se relacionam e decidir o que acontece nos caminhos menos óbvios — como uma falha de rede, uma comparação empatada ou uma permissão insuficiente.

É nesse processo que tecnologias e conceitos ganham contexto. Em vez de estudar uma ferramenta de forma abstrata, posso entender onde ela ajuda, quais limites tem e como afeta a experiência de quem usa o produto.

GitHub Pokédex Card: dados transformados em uma ficha

O GitHub Pokédex Card transforma informações públicas de um perfil do GitHub em uma ficha visual de personagem desenvolvedor. O card reúne classe, atributos, progressão, raridade, linguagens e estatísticas públicas, além de poder ser compartilhado ou baixado como PNG. O projeto também compara dois perfis em um modo de batalha.

O desafio interessante aqui é transformar dados incompletos e diferentes entre si em uma experiência divertida sem fingir que eles dizem mais do que realmente dizem. A API pública retorna, por exemplo, até 100 repositórios recentes e eventos públicos disponíveis — não o histórico completo de contribuições. Por isso, o app explicita os limites da amostra e não inventa uma contagem anual de contribuições que a API não fornece.

As regras da ficha ficam em funções de domínio independentes da interface, e os cálculos são determinísticos. Isso torna importante pensar não só em como calcular atributos, XP e raridade, mas também em como explicar de onde vieram os resultados. Foi um exercício de modelagem: criar uma camada de jogo sobre dados reais sem perder transparência.

Analize: registrar partidas para entender o desempenho

O Analize é um app mobile feito com Expo e React Native para registrar sessões de jogo, partidas, análises agendadas e métricas de desempenho. Em vez de tratar todo jogo da mesma maneira, o app usa um catálogo compartilhado: cada jogo pode ter seus próprios modos, condições e definições de métricas.

Essa decisão influencia o fluxo inteiro. Uma sessão pertence a um grupo e herda o jogo escolhido nele; o formulário de uma partida usa as métricas configuradas para aquele jogo; e os gráficos podem ser filtrados por grupo, sessão, partida, condição e outros recortes.

Também há desafios para além da interface: organizar grupos e participantes, convites e notificações, manter os registros úteis para análise e considerar o uso quando a conexão falha. Trabalhar nesse tipo de aplicação reforça como uma decisão de modelo de dados repercute em formulários, navegação e visualizações.

HorizonQuest: quests, revisão e progressão

O HorizonQuest é um sistema gamificado de quests com submissões, revisão, XP e progressão de jogadores. A aplicação é organizada como um monorepo: o frontend usa React, Vite e Tailwind, enquanto a API é construída com Express, Prisma e PostgreSQL.

Um fluxo de quest envolve mais do que enviar uma resposta. Há papéis diferentes, uma fila de revisão, aprovação ou rejeição com comentário, atualização de XP e desbloqueio de conquistas. As permissões precisam ser verificadas também na API, e não apenas escondidas na interface. Por exemplo, quem revisa não pode aprovar a própria entrega.

O projeto também cresceu para incluir áreas como projetos da guilda, diário privado, taverna e uma loja de itens cosméticos. Esse conjunto mostra como funcionalidades aparentemente independentes dependem de regras coerentes de acesso, histórico e relacionamento entre usuários. É uma oportunidade de pensar em comportamento consistente à medida que um produto ganha novas partes.

FOCAra: estruturando instruções para IA

O FOCAra ajuda a transformar uma necessidade em uma instrução clara e personalizada para diferentes ferramentas de IA. A pessoa escolhe uma categoria, responde perguntas guiadas e recebe um prompt estruturado pelo método FOCO, que pode então copiar, editar ou gerar novamente.

O fluxo inclui categorias para estudos, programação, trabalho, pesquisa, escrita e negócios. O histórico fica local, com busca, filtros e resumo, e o produto não depende de uma IA específica para que a instrução final possa ser usada.

Construir uma experiência assim exige pensar em como fazer perguntas úteis sem tornar o processo cansativo e como apresentar um resultado que a pessoa consiga entender e adaptar. Também envolve separar responsabilidades: a interface guia o preenchimento, enquanto a geração server-side usa uma API externa para organizar a instrução.

O que esses projetos estão me ensinando

Olhando para esses projetos em conjunto, vejo alguns aprendizados que aparecem em contextos bem diferentes:

• Modelar antes de acumular telas: entidades e regras bem pensadas ajudam a manter os fluxos coerentes.
• Ser transparente sobre os dados: deixar claro o que é observado, calculado ou limitado evita criar expectativas falsas.
• Aplicar permissões no lugar certo: controles visuais ajudam na experiência, mas a API também precisa proteger as operações.
• Pensar em falhas e estados: rede indisponível, dados parciais, empates e submissões rejeitadas fazem parte do produto.
• Explicar sistemas complexos com clareza: métricas, progressão e formulários precisam ser compreensíveis para quem usa.
• Evoluir em etapas: produtos maiores são construídos por partes, com decisões revistas conforme surgem novos requisitos.

Também tenho aprendido que um projeto fica mais interessante quando a tecnologia serve a uma necessidade clara. A stack importa, mas as decisões sobre o problema, os dados e as pessoas que vão usar a solução importam tanto quanto.

Próximos passos

Quero continuar aprimorando esses projetos, dando atenção tanto às regras internas quanto à experiência de uso. Também quero seguir explorando novas ideias que me façam aprender algo concreto — seja sobre arquitetura, dados, desenvolvimento mobile ou a forma de transformar uma necessidade em um produto.

Mais do que acumular tecnologias, quero construir soluções que me desafiem a pensar melhor e a tomar decisões com mais clareza. Cada projeto é uma oportunidade de praticar esse processo: entender o problema, fazer escolhas, observar o resultado e continuar evoluindo.