DEV Community: Anderson Nieves

Diário Dev7: Por que decidi criar meu próprio design system?

Anderson Nieves — Mon, 29 Dec 2025 14:16:52 +0000

Essa provavelmente será a última postagem do ano. Em vez de fazer uma retrospectiva do projeto, quero aproveitar para apresentar algo novo!

Há um bom tempo, enquanto eu ainda mostrava os mockups para um amigo que também é desenvolvedor, ele comentou algo que ficou na minha cabeça. Ao ver uma página no Figma cheia de componentes e suas variações, ele disse: “Nossa, parece que você está fazendo um design system.”

Aquilo me marcou, porque sim, eu já havia trabalhado em empresas que criavam seus próprios design systems, mas nunca cheguei a atuar diretamente no time que os mantinha. Eu apenas consumia os componentes e seguia as guidelines.

Outra coisa que me veio à mente foram as decisões que tomei neste projeto. Lembro de ter mencionado aqui antes que algumas escolhas seriam voltadas também para o meu desenvolvimento pessoal. Por isso decidi criar os componentes do zero, mesmo sabendo que isso tornaria o projeto mais demorado. Só não imaginava que levaria tanto tempo.

Fiquei com a fala do meu amigo na cabeça e percebi o quanto desenvolver componentes e guidelines do zero é trabalhoso, principalmente sendo um projeto solo.

Fiquei com a fala do meu amigo na cabeça e percebi o quanto desenvolver componentes e guidelines do zero é trabalhoso, principalmente sendo um projeto solo.
Aí pensei em aproveitar o que já tinha feito e transformar isso em um projeto paralelo, um design system/biblioteca de UI para React. Assim, nasceu o ModleKit, que inicialmente vai servir como uma biblioteca de componentes para o Mangos.

Pesquisei sobre design systems e como eles diferem das bibliotecas de componentes de UI. Inicialmente, entendi que um design system é mais abrangente e inclui uma biblioteca de UI. Enquanto uma biblioteca de UI se concentra em elementos reutilizáveis como botões, cards, modais, formulários e outros, um design system compreende a biblioteca, diretrizes para consistência, design tokens para cores e espaçamentos, e uma documentação extensa. No contexto do meu projeto, acredito que o MoldeKit começará como uma biblioteca, mas à medida que evoluir e se tornar mais completo, poderá se tornar um design system completo.

Estou animado e um pouco apreensivo com este projeto. É a primeira vez que crio algo assim, e ele claramente não se destina a uso em produção ou outros projetos. Em vez disso, é um portfólio para demonstrar meu conhecimento e promover meu desenvolvimento pessoal, o que deixo bem claro na documentação do projeto. Espero não estar divergindo muito do projeto do Mangos. Minha estratégia é a seguinte: inicialmente, o MoldeKit conterá apenas componentes para suportar a interface do Mangos. À medida que eu finalizar os componentes que pretendo usar no Mangos, eles serão disponibilizados no MoldeKit.

Agora, quando começo um novo projeto, já tenho meus próprios componentes prontos para agilizar o processo. Deixo aqui embaixo o link do Repositório e do Storybook do projeto para quem quiser conferir e contribuir.

Diário Dev #6: Persistência, pausas e revisitar ideias no desenvolvimento

Anderson Nieves — Mon, 01 Dec 2025 21:52:40 +0000

Já fazem algumas semanas desde a última postagem. Eu pretendia voltar a escrever apenas quando eu tivesse algo mais substancial para demonstrar, mas como a ideia era para ser meu diário, faz parte escrever sobre as semanas em que eu fico preso em algo ou mal consigo avançar com alguma ideia.
Entre o último post e esse de agora, eu tirei férias, foram 15 dias totalmente desconectado para recarregar as energias. Retornando, tentei continuar o projeto de onde eu havia parado. Com a cabeça fresca, acabei achando uma boa ideia revisitar alguns pontos, fazendo um rework de algumas coisas no lado do front-end, ao menos dos mockups das telas.

Eu passei algumas semanas fazendo alterações nos componentes da interface. A ideia era deixar as coisas mais consistentes, tanto em questão de tamanho dos itens, bordas, margins e tipografia quanto em relação às cores que estavam em alguns pontos com contraste insuficiente. Essa foi a pior parte, ajustar as cores para manter de um jeito em que era esteticamente agradável e ao mesmo tempo com contraste suficiente para ajudar na legibilidade e acessibilidade. Revisitei também alguns componentes de visualização de dados, os famosos gráficos. Peguei algumas inspirações em projetos postados no Pinterest para deixar mais fácil de entender e visualizar a informação que eu queria passar.

Fiquei de início um pouco chateado por estar revisitando esses pontos, estou ansioso para ver o projeto implementado e funcionando logo. Essa expectativa e ansiedade eu vou ter que aprender a lidar com elas, eu sei que é um esforço grande e que vai levar tempo até o MVP estar pronto, não só pelo tempo de implementação, mas também considerando que nessa jornada eu também estou fazendo muitas coisas pela primeira vez, investindo muito tempo em pesquisa, aprendizado e testes. Estamos falando de uma equipe de um só, do esforço de uma pessoa que já possui um trabalho de tempo integral e tenta encaixar esse projeto em meio ao trabalho, vida pessoal e a outros hobbies como o rugby e academia. Me vejo alguns finais de semana mais entretido no projeto, mas em alguns eu preciso espairecer e deixar o projeto um pouco de lado.

Refleti um pouco também sobre o porquê eu achei ruim ter que revisitar os componentes dos mockups. Eu estava com uma mentalidade muito “cascata” sobre o projeto, mesmo sabendo que não é assim que as coisas acontecem em ambientes ágeis. É normal revisitar etapas em um processo de melhoria contínua. O que eu tenho que tomar cuidado é: Lembrar que sou apenas eu, em equipes reais de trabalho existem pessoas dedicadas para cada função e faz parte do trabalho desses profissionais revisitar e evoluir o trabalho deles em iterações ao longo do tempo. Eu não posso me prender em um loop de melhorias apenas no front-end e deixar de desenvolver o resto. Apenas esse ponto em que eu tenho que me atentar.

Bom, tem mais coisas que eu teria que falar sobre essas últimas semanas, mas para não deixar o texto longo demais, vou deixar para o próximo, que se tudo der certo vai vir logo. Posso apenas dizer que tem a ver com um side-project de uma biblioteca de componentes de UI.

Diário Dev #5 - Minha jornada no design da interface

Anderson Nieves — Mon, 01 Sep 2025 00:45:03 +0000

Antes de mais nada, quero avisar que não desisti do projeto! Eu sei que já fazem algumas semanas desde a última postagem. Estive trabalhando no repositório público e nos mockups, com isso fui adiando as postagens aqui, pois muito que bem. O projeto agora possui um repositório GitHub. Estou me baseando na prova de conceito desenvolvida anteriormente, seguindo tudo que já havia sido validado, e adicionando o pipeline de infraestrutura, aplicando IaC (Infraestrutura como Código) no projeto. Como o foco deste artigo não é falar sobre esse tema, segue um artigo da AWS sobre IaC e seus benefícios.

Ainda faltam criar os templates de outros componentes da infraestrutura, como o API Gateway, as Lambdas e o User Pool do Cognito. Essas etapas vão me tomar algum tempo, principalmente por conta da pesquisa. Estou acostumado a criar recursos pelo portal da AWS, descrever a infraestrutura em arquivos .yaml é novidade para mim. Já havia estudado o tema e feito exercícios introdutórios com CloudFormation e Terraform, nada além do básico.

Caso queira conferir o repositório do projeto, aqui estão os links:

Repositório: https://github.com/andersonvnieves/mangos
App publicado: https://mangos.avn.dev.br

No frontend eu fiz apenas um bootstrap do projeto, configurando as bibliotecas que eu vou usar, preparando o pipeline, os recursos de Infraestrutura com IaC e pude ver funcionando de ponta a ponta. Por hora se você acessar o link do projeto vai ver isso apenas:

Depois dessa atualização sobre o andamento do projeto vamos ao assunto principal deste artigo.

Hoje quero falar um pouco sobre como foi o processo de design, de criação dos mockups, levando em consideração que eu não sou um designer de interfaces. Comecei ouvindo as vozes da minha cabeça… brincadeira. Na verdade eu comecei o processo procurando conteúdos sobre o tema de quem já trabalha com isso, existem vários canais no Youtube de designers de UI que acabam dando dicas de como desenhar interfaces. Existe também muito portfolio de designes no dribbble e no behance. No pintrest você também consegue achar várias dicas de design de interfaces como por exemplo a regra 60-30-10.

É muito fácil para alguém que não é designer errar a mão na hora de aplicar cor na interface, criar algo visualmente desagradável ou que não direciona a atenção do usuário aonde ela deve ir. Então existem algumas dicas como a regra 60-30-10 para te ajudar a aplicar melhor as cores da sua paleta na interface:

Porção 60 seria destinada as fundos e painéis com cores mais neutras.
Porção 30 seria mais destinada aos textos da interface, sendo essa uma cor com um bom nível de contraste com a cor dos fundos.
Porção 10 que seria uma cor de destaque, geralmente uma cor ligada a marca no caso de um produto. Essa cor se reserva para os “call to action”, ou pontos de interação para o usuário.

Algumas dicas são mais fáceis de ser compreendidas e aplicadas, como por exemplo uma dica simples de como fazer as bordas dos elementos ficarem mais agradáveis visualmente.

Existem vários outros exemplos como esse. Paralelo a isso fui fazendo um benchmarking, avaliando a interface de aplicativos de finanças pessoais que já existem na Play Store e App Store. Isso me ajudou a identificar pontos em que todos os apps tinham em comum, como elementos eram adaptados entre smartphones e desktop em um app semelhante ao que quero desenvolver.

Um ponto de atenção aqui é que esses eram de fato apps mobile (.ipa e .apk), o meu se trata de um web app, ou seja, ainda sim existem diferenças na interface desses dois, por exemplo:

Se você analisar alguns apps nativo de celular a navegação é feita com navigation bars, aquele componente de menus que fica na parte de baixo da tela:

Ele é ótimo para apps nativos que ocupam a tela inteira dos dispositivo, mas para web apps que rodam dentro de um navegador, o espaço na vertical acaba sendo reduzido pela própria interface do navegador.

Então acaba sendo comum web apps utilizem side menus, que fazem uma sobreposição no conteúdo ao serem acionadas e depois somem, assim não ocupando um espaço valiso da pequena tela o tempo inteiro, mesmo quando não em uso. Mesmo apps que contam com web app e app nativo fazem essa distinção. Esse foi o tipo de coisa que investi um pouco de tempo observando em outros apps para ter mais bagagem na hora de pensar na interface do meu projeto.

Estou utilizando o Figma para desenvolver o mockup, ele tem vários recursos interessantes que atendem perfeitamente as necessidades de um projeto pequeno como o meu no nível gratuito. Existem alguns recursos mais avançados para a criação de protótipos navegáveis com condicionais mas alguns desses recursos acabando ficando para as versões paga.

Juntando tudo isso, eu comecei criando no Figma alguns wireframes, que são rascunhos bem simplificados usados pra visualizar a estrutura e disposição dos itens da interface.

Assim eu já pude definir como mais ou menos seria o comportamento e disposição dos cabeçalhos, menus de navegação, uma certa área de contexto (que terá comportamento diferente no desktop, tablet e smartphone) e da área do conteúdo principal.

Acredito já ter mencionado em outras postagens que para esse projeto eu escolhi não utilizar bibliotecas de componentes prontas, nada contra elas, apenas queria passar pelo processo de desenvolver os componentes do zero. Isso fez com que na hora em que eu iniciei o desenvolvimento dos mockups e dos componentes da interface, eu tivesse uma enorme quantidade de tentativas e retrabalhos. Esse é inclusive um processo que acredito que sempre pode ser revisitado no projeto. Então mesmo futuramente quando eu estiver próximo de concluir as funcionalidades o MVP, não vejo problema em fazer melhorias de interface no projeto.

Este texto já está ficando bem longo, para finalizar gostaria então de mostrar o mockup de uma tela chamada “Visão Geral”. Essa tela é uma das principais, ela é que essencialmente substitui o que eu vejo na planilha de Excel. Uma única tela que me mostra todos os recebimentos, despesas, valore investidos e os gastos diários também para cada mês. Permitindo a navegação entre os meses. Tanto para os meses históricos quanto para os futuros, fazendo uma previsão:

Está e a visão no desktop pequeno como em notebooks, então temos um menu de navegação contraído á esquerda podendo ser expandido revelando as labels dos ícones mas por padrão aparecendo contraído mesmo. Em uma visão desktop grande, como em telas grandes, esse menu já poderia aparecer expandido. Então temos uma área grande que se diferencia pela cor de fundo que se destina ao conteúdo principal da tela. e a direita uma barra lateral que se destina a um conteúdo mais dinâmico, exibindo detalhes de onde o usuário selecionar. Neste exemplo, na listagem de gastos diários, o dia 9 está selecionado, então essa barra lateral dinâmica está mostrando detalhes dos gastos do dia 9.

Na visualização de tablet, temos as mesmas informações mas dispostas de forma adaptada ao formato e tamanho do dispositivo. O menu de navegação lateral nessa visualização já vem escondido e aparece um novo componente de cabeçalho no topo da tela com um botão menu, que revelaria o menu de navegação, este formato de componente costuma ser chamado de “navigation drawer”. Outra mudança é que a área principal passa a ocupar a tela inteira na horizontal e o conteúdo dela passa a ser organizado em 2 colunas em vez de 3 na versão de desktop. Por fim a barra lateral direita de conteúdo dinâmico passa a não existir, sendo substituída por um tipo de componente chamado “bottom sheet”, algo parecido com um modal mas que aparece na tela pela parte de baixo e se sobrepõe ao conteúdo sendo exibido, assim que a interação com ele acaba, ela some e o conteúdo que estava por baixo se torna visível novamente.

E por último, a menos visualização do app, a de smartphone. Aqui mantive muito das mudanças feita na visualização de tablet. A grande diferença está na área principal, que pelo tamanho dos dispositivo passa a ter apenas 1 coluna e ganha um componente de aba logo abaixo do título da página para alternar entre os conteúdos que eram exibidos em 2 colunas na versão de tablet.

Com isso encerro o conteúdo sobre como foi o processo para fazer o design da interface sendo uma pessoa que não é designer. Vou continuar ao longo das semanas postando sobre o andamento do projeto.

Diário Dev #4 – Arquitetura full stack serverless com React, .NET 8 e AWS

Anderson Nieves — Tue, 29 Jul 2025 15:39:32 +0000

Passei as últimas semanas trabalhando em uma prova de conceito que me ajudasse a validar a arquitetura da solução antes de iniciar o desenvolvimento do MVP. O objetivo era testar a stack escolhida, a integração dos serviços da AWS escolhidos e se eles se mantivessem dentro do nível gratuito do AWS.

Trata-se de uma etapa muito importante do projeto, validar a arquitetura agora evita problemas no futuro, mas não elimina 100% a chance de aparecerem. Até por porque um software desenvolvido de maneira ágil está em constante evolução, os requisitos funcionais e não funcionais podem mudar fazendo com que a solução inicial não atenda mais a nova realidade e precise de revisões.

Voltando ao meu caso, ter essa visão cedo me permite antecipar problemas, como incompatibilidade entre os serviços ou tecnologias escolhidas. Sem validar antes, eu só descobriria alguns obstáculos mais adiante no desenvolvimento, atrasando o projeto, gerando custos (no caso de projetos corporativos) e também retrabalho. Agora que conclui essa etapa, gostaria de detalhar as escolhas feitas e o motivo por trás delas.

Arquitetura Serverless

Por se tratar de um projeto com apenas uma pessoa desenvolvendo, uma arquitetura que necessite de pouca manutenção e baixa complexidade é exatamente o que eu preciso. Por isso estou utilizando apenas serviços serverless dentro do AWS. O foco desse artigo não é explicar sobre serverless mas para quem quiser uma definição rápida, o blog da IBM resume bem:

Serverless é um modelo de execução e desenvolvimento de aplicações de computação em nuvem para que os desenvolvedores criem e executem códigos de aplicação sem precisar provisionar nem gerenciar servidores e infraestruturas de back-end.

Se quiser saber mais, você pode ler o texto completo neste link

O diagrama acima mostra os serviços do AWS utilizados para compor a solução e a integração entre eles, para explicar cada componentes, vou separar a explicação da arquitetura em alguns grupos, front-end, back-end, armazenamento, observabilidade e CI/CD:

Front-end

Para esse projeto, uma aplicação Single Page Application (SPA) já era suficiente. Não há necessidade de Server-Side Rendering (SSR) o que simplifica bastante pra mim, especialmente em um ambiente serverless. Uma SPA não necessita de um servidor de aplicação em execução contínua, posso simplesmente gerar os arquivos estáticos e servi-los diretamente de um bucket do S3 com a função de static website hosting ativada.

A escolha da biblioteca / framework front-end ficou entre duas opções muito consolidadas: React e Angular. Aqui ambas se sairiam muito bem, mesmo com suas particularidades. Acabei optando pelo React por uma serie de motivos técnicos e pessoais, entre eles o desejo de aprofundar meu conhecimento em React já que minha experiencia mais sólida é com o Angular. Esses critérios e diferenças entre as duas opções inclusive, poderiam render uma postagem futura.

Back-end

Já trabalhei anteriormente com o .NET 8, o que tornou a escolha uma decisão segura. Ainda não experimentei alguns recursos como as Minimal APIs e o AOT (Ahead-of-Time Compilation). Esse projeto será uma oportunidade pra explorar esses recursos de forma prática, em vez de investir um tempo para aprofundar meu conhecimentos em outros frameworks de outras linguagens como o Spring Boot no Java (que tenho uma experiencia mais básica) ou algo mais distinto como Go usando Gin. Assim como os critérios de decisão entre Angular e React, aqui cabe também um texto futuro sobre a escolha entre .NET, Java ou Go. Que foram as tecnologias que eu cogitei utilizar.

Então meu projeto será composto de algumas APIs rodando em funções Lambdas independentes, todas expostas para o front-end através do API Gateway, atuando como uma camada de roteamento e controle de acesso, aproveitei os recursos de throttling para limitar o número de requisições por segundo e por cliente protegendo a API (não que eu espere um tráfego alto na aplicação, mas caso aconteça algum abuso, essas proteções configuradas podem me poupar de uma surpresa inesperada na fatura da AWS).

O API Gateway está integrado com o Cognito, fazendo um fluxo de autenticação desde o front-end SPA até as rotas da API, tudo com o mesmo userpool. Esse modelo permite uma arquitetura completamente serverless, segura e escalável.

Banco de Dados

Pensando em manter a proposta de uma arquitetura serveless, optei por utilizar o Amazon DynamoDB como banco de dados. Aqui não teve muita dúvida, além de ser um serviço totalmente gerenciado e escalável, o DynamoDB está incluso no nível gratuito da AWS, uma excelente escolha para projetos pessoais e MVPs.

Como estamos falando de um banco NoSQL, baseado em chave-valor e documentos, é necessário uma modelagem de dados diferente da relacional utilizada nos bancos SQL. Esse ponto acaba sendo uma oportunidade ótima para eu estudar e praticar uma modelagem diferente, baseada em padrões de acesso em vez de normalização e relacionamentos. O DynamoDB não suporta “joins” entre as tabelas como acontece em um banco relacional, então as tabelas tem que ser pensadas para retornar basicamente todos os dados de uma vez. É comum consolidar dados diferentes em uma única tabela para otimizar performance, podendo haver duplicação de dados. Por isso a modelagem das tabelas começa pelas consultas que serão feitas.

Observabilidade

Todos os serviços da AWS utilizados no projeto enviam logs e métricas de uso automaticamente para o AWS CloudWatch, permitindo um monitoramento centralizado dos erros e comportamentos, e da saúde das aplicações.

Através do CloudWatch é possível acompanhar várias métricas importantes desde erros de execução nas funções Lambda, taxas de requisições, códigos de status HTTP retornados pelo API Gateway e consumo de leitura/escrita no DynamoDB. Também e possível configurar alarmes com base nas métricas quando atingirem níveis anormais, enviando notificações por e-mail via SNS. Assim podemos agir rapidamente em casos de problemas ou abusos e restaurar a aplicação um estado saudável e evitar custos desnecessários.

Por fim, caso apareça a necessidade, seja para estudo ou para lidar com cenários mais complexos, existe a possibilidade de adicionar o AWS X-Ray para habilitar um rastreamento continuo entre os serviços, visualizando uma requisição de ponta-a-ponta, passando por todos os serviços e identificando pontos de gargalos, latência ou falhas ao longo da execução.

CI/CD

A etapa de CI/CD, até o momento, é a única que utiliza serviços de fora da AWS. O repositório com código-fonte está hospedado no GitHub por dois motivos: O primeiro pelo GitHub ser onde normalmente os desenvolvedores colocam sues projetos de portfólio. O segundo motivo é que a AWS está depreciando seu serviço de repositórios Git, o AWS CodeCommit.

Além disso, o GitHub inclui um serviço de CI/CD integrado, o GitHub Actions, que oferece 1000 minutos de execução por mês gratuitos para contas pessoais (o que é mais que o suficiente pra esse projeto). Com isso a cada a na branch alteração na branch de um ou mais repositórios (ainda não me decidi sobre utilizar monorepo ou não), um pipeline é disparado realizando as etapas de compilação, execução de testes e deploy de artefatos para os serviços da AWS. Toda a configuração das Actions ficam em arquivos .yaml que são versionados no próprio repositório. Esse fluxo já foi testado na prova de conceito desenvolvida anteriormente.

Outra funcionalidade importante do GitHub é o suporte a variáveis e segredos de repositório. Eles funcionam de forma análoga ao AWS System Manager Parameter Store (que armazena variáveis referente ao projeto como, como uma URL de retorno por exemplo) e ao AWS Secrets Manager (que armazena informações sensíveis como strings de conexão com bancos da dados ou chaves de APIs), permitindo um controle e armazenamento seguro dessas parâmetros que são necessários durante o processo de build e deploy.

Lições aprendidas

Como disse no inicio do texto, fazer uma prova de conceito era importante para identificar problemas cedo e adaptar a solução antes de avançar muito no desenvolvimento.

Durante essa etapa esbarrei em uma limitação importante, o Amazon S3 com static website hosting não oferece suporte a servir as páginas em HTTPS, aparentemente mesmo utilizando um domínio próprio via Route 53.

Isso virou um obstáculo porque o AWS Cognito, utilizado aqui como Identity Provider (para fazer autenticação e autorização) exige que as URLs de redirecionamento sejam HTTPS com exceção apenas do localhost para testes.

Pesquisando por uma solução, descobri que ao adicionar uma distribuição do CloudFront em frente ao bucket S3 seria possível servir a aplicação SPA via HTTPS e utilizando essas URLs nos callbacks do Cognito, viabilizando a integração. Não adicionei o CloudFront pensando em receber um grande volume de tráfego aproveitando as capacidade dele como CDN, mas sim para contornar essa limitação técnica de HTTPS.

De quebra o CloudFront ainda trás alguns recursos legais que podemos explorar no futuro como por exemplo restringir o tráfego por região geográfica, isso pode ser útil em alguns cenários como evitar tráfego indesejado de bots ou regiões com alto índices de ataque. Movendo o API Gateway para atrás do CoudFront ganhamos também a capacidade de fazer cache de requisições (quando aplicável) para dados públicos ou raramente mutáveis por exemplo.

Considerações Finais

Esse foi um texto longo, e olha que eu tentei resumir ao máximo sem comprometer o conteúdo. Mas isso é para mostrar a quantidade de possibilidades e decisões que fazem parte do processo de pensar e repensar a arquitetura de um sistema. Isso considerando que esse é um projeto pequeno e que está nas fases iniciais, começando a sair do papel. Espero ter conseguido demonstrar o valor desse processo tanto no ponto de vista técnico quando de aprendizado.

Para as próximas semanas, minha expectativa é implantar os ambientes reais na AWS. Vou também continuar documentando a jornada aqui, com postagens sobre os desafios, aprendizados que estão surgindo.

Diário Dev #3 – Meu MVP é um Excel?

Anderson Nieves — Wed, 09 Jul 2025 16:11:49 +0000

No post passado eu tratei da importância de seguir as etapas da engenharia de software principalmente das fases iniciais de planejamento e design. Hoje quero falar um pouco mais sobre o Produto Mínimo Viável (MVP). Não sei dizer quando o conceito foi criado, mas ele certamente se popularizou no meio das startups com aquele livro da capa azul "The Lean Startup” do Eric Ries publicado em 2011.

Primeiro vamos definir do que se trata, um MVP é uma versão de um produto que permite a equipe validar hipóteses com usuários reais. Ele ajuda a responder questões sobre seu produto como: As pessoas realmente querem isso? Elas pagariam? Como elas usam no dia a dia? Em outras palavras, é um estágio de aprendizado e validação da solução. Quando a startup começa a escalar o produto se torna uma versão em evolução não mais um MVP.

No mundo do empreendedorismo e das startups a ideia do "fail fast” está intrinsecamente ligada aos MVPs, startups em suas fases iniciais não tem tantos recursos e tempo para testarem suas ideias e produtos, então adotam a filosofia de errarem mas errarem rápido! Assim elas conseguem direcionar o produto na direção correta com base no que aprenderam. O MVP é a ferramenta que possibilita aplicar esse pensamento.

Não vamos confundir MVPs com protótipos, enquanto os MVPs buscam validar hipóteses e são funcionais, ou seja, entregam valor ao usuário, os protótipos são rascunhos visuais que podem ser rapidamente alterados. Ao contrário dos MVPs, os protótipos são simulações, geralmente não apresentam funcionalidade real, podem ser de baixa ou alta fidelidade e podem ser distribuídos entre equipes internas, investidores e potenciais usuários.

Tudo isso se aplica a startups e empresas desenvolvendo um produto, como vou aplicar esses conceitos e ideias no meu projeto pessoal? Bem, a planilha que eu uso até hoje seria um MVP puro em essência. Ela sofreu iterações de melhorias ao longo do tempo, portanto se ajustando aos “feedbacks de usuário”. Eu a uso com frequência, ou seja sou um usuário real e por hora ela resolve meu problema, logo o modelo lógico de organizar as informações está validado.

O próximo passo seria o MVP em formato de WebApp. Este por ser distribuído em um canal diferente (web em vez de arquivo Excel) se levantam novas hipóteses que precisam ser validadas: É possível utilizar facilmente pelo celular e fora de casa? A usabilidade é boa? A experiencia é consistente entre as versões desktop e mobile?

Com o WebApp MVP ganhamos uma melhora da experiencia, escalabilidade e portabilidade. Neste ponto em que eu pretendo acabar o projeto, antes que ele atinja uma fase de maturidade de produto evoluindo. Se tivesse atingido essa fase as preocupações seriam em robustez, escalabilidade, performance, segurança e diferencias de mercado.

Acho que isso resume bem os conceitos de MVP e como estou adaptando isso para a realidade do meu projeto. Nas próximas semanas quero fazer um texto sobre a arquitetura da solução e as provas de conceitos que eu fiz antes de iniciar o desenvolvimento real do MVP.

Diário Dev #2 – SDLC, como planejamento pode salvar seu projeto

Anderson Nieves — Sat, 28 Jun 2025 17:18:12 +0000

No Ciclo de Vida de Desenvolvimento de Software (SDLC) temos 8 grandes etapas que ajudam a estruturar e visualizar melhor o processo, são elas: Planejamento, Análise de Requisitos, Design de Sistema, Desenvolvimento, Teste, Implantação, Manutenção e Revisão/Retrospectiva.

Em tentativas anteriores de fazer um projeto passei por dificuldades por ter considerado desnecessárias etapas da engenharia de software como planejamento, análise de requisitos e design de sistema. Por serem projetos pequenos e desenvolvidos por uma pessoa só, pensei que pelo tamanho do escopo eu daria conta de pensar em todas essas coisas à medida em que ia desenvolvendo. A verdade é que não dá.

Começar diretamente na fase de desenvolvimento, seja para testar logo algo que você passou os últimos dois meses estudando ou tentando ir direto ao ponto para terminar mais rápido acaba sendo um tiro no próprio pé. Sem um planejamento anterior, você não tem uma noção da sua arquitetura, não tem uma definição clara dos requisitos, não tem um protótipo da sua interface, não sabe se o que você está tentando utilizar faz sentido ou é apenas um capricho seu.

À medida que você implementa novas funcionalidades percebe que precisa revisitar o que você já fez pois o código existente não acomoda bem as novas funcionalidades. A UI passa a não ser coesa. Chega a um ponto em que você acaba desistindo, ver sua ideia funcionando se torna mais distante pelas refatorações que agora seriam necessárias.

Por se tratar de um modelo conceitual, posso e devo adaptar as etapas ao meu projeto. Por exemplo, em projetos ágeis (como o que estou fazendo), essas etapas existem, mas acontecem de forma diferente, são iterativas e menos formais, a documentação pode ser simplificada também. Com MVPs e protótipos, é aceitável afrouxar os testes (com responsabilidade), pois o foco é aprender rápido e validar hipóteses e não garantir “perfeição” técnica. Outro ponto é que, geralmente, nessas etapas, os requisitos ainda são instáveis, podem sofrer muitas alterações, portanto, testar com profundidade algo que tem grandes chances de mudar ou ser descartado não é eficiente.

No projeto do app de finanças, atualmente, estou perto de iniciar o desenvolvimento. Passei um tempo nas etapas iniciais, na fase de Planejamento, escrevi um PRD (Product Requirement Document), que é um documento que os Gerentes de Produtos descrevem os objetivos, problemas que o produto resolve, funcionalidades principais, regras e restrições e, por último, métricas esperadas (esse último eu não coloquei, por não ser um produto que vai para o mercado, não acompanharei nenhuma métrica).

Queria simular um ambiente de trabalho, então, por ser uma ferramenta bastante utilizada, configurei uma conta da Atlassian no nível gratuito e estou utilizando o Confluence para a documentação. Como eu já havia decidido utilizar os recursos do AWS, comecei a desenhar uma arquitetura, fazendo uma prova de conceito PoC se ela funcionaria da maneira em que eu imaginei. Utilizei também o AWS Pricing Calculator que me permite simular o custo mensal de ter minha solução funcionando.
Passando para a fase de Análise de Requisitos, criei histórias de usuário no Jira com base no meu PRD e foi aqui em que eu entendi seu valor. Ele tem sido meu norte nesse processo, sendo revisitado à medida em que vou avançando ou vendo necessidade de refinar algo.

Em paralelo, fui desenvolvendo um protótipo da interface no Figma para completar o entendimento das histórias. Aproveitando para tentar aplicar outro conceito na hora de desenhar a interface e os componentes, que é o Atomic Design, ele ajuda a estruturar a interface e na interação dos componentes, percebi que essa me faz visualizar já como seria a implementação e separação dos componentes no React, acredito que vai me trazer maior clareza e agilidade na hora de codificar.

Estou aprendendo muito nessa jornada, seguir o SDLC mesmo que de forma adaptada está me dando clareza e foco. Agora que eu tenho quase tudo no lugar, pretendo mover para a fase de desenvolvimento, então logo já devo disponibilizar o repositório público do projeto.

Diário Dev #1 – O Problema e as Expectativas

Anderson Nieves — Thu, 19 Jun 2025 00:29:53 +0000

Praticamente todos os projetos de software partem de um ponto em comum, solucionar um problema real de um usuário (indivíduo ou organização). Hoje quero apresentar o problema que quero solucionar e deixar algumas expectativas esclarecidas em relação a decisões que vou tomar durante o processo.

Desde 2015 faço um controle dos meus gastos através de planilhas do excel. Ao longo desses anos essas planilhas foram modificadas para se adaptar ao jeito que gerencio meu dinheiro e também a dicas que aprendi vendo conteúdos de finanças pessoais online. Algumas vezes as modificações realmente pareciam ter vindo de requisitos de software, uma vez alterei todo o layout da planilha para que ficasse fácil de abri-las pelo celular mantendo tudo em colunas curtas para uma visualização mais na vertical.

Essas planilhas me ajudam a organizar minhas despesas nos meses seguintes, acompanhar o mês atual com as contas e faturas que vão fechar, as que ja paguei e meus gastos diários. Consigo também me planejar para gastos futuros, como viagens e compras parceladas.

Basicamente para cada mês, consigo em uma única aba visualizar os seguintes grandes grupos:

Recebimentos: tudo o que entra na minha conta, como salário, adiantamento de 13°, bonus, férias, reembolso de plano de saúde e por ai vai.
Despesas: Sejam elas contas de consumo, faturas de cartões, assinaturas. E no caso dos cartões consigo ver meus parcelamentos de cada cartão.
Investimentos/guardar: Aqui fica registrado o valor e para qual objetivo vou guardar esse mês, como por exemplo, valor que vou guardar para uma reserva de emergencia, uma viagem, etc.
Gastos diários: Estipulo uma cota de gastos por dia que pode varias se for dia de semana, feriado, algum evento ou férias. É mais como um orçamento que me ajuda a controlar os gastos no dia a dia.
Resumo: Uma sessão com os valores agregados dos outros grupos e um saldo livre do mês.

Paralelo com as planilhas, eu guardo no meu drive todas os boletos/faturas e seus respectivos comprovantes de pagamento separados em pastas por ano e mês.

Parece muito o que apps financeiros existentes já fazem não? Pois é, várias vezes já me peguei pesquisando sobre aplicativos de finanças existentes ou ate vendo algumas funcionalidades que os próprios aplicativos de bancos disponibilizam hoje em dia.

Fiquei receoso em migrar para esses apps existentes pois alguns possuem recursos pagos, eu gastaria muito tempo tentando criar contas e testados várias opções. Fui vencido por esses pensamentos afinal as planilhas já estavam lá certo ? Já funcionavam e eu estava acostumado com elas.

Ao mesmo tempo as planilhas são chatas de manter, as vezes acontecem erros de sincronização no drive, não são fáceis assim de manipular no celular (por mais que eu tente). Algumas operações são mais manuais do que eu gostaria de admitir. Os valores entram manualmente na planilha, acontecem inconsistências entre os valores que eu supostamente teria em conta pelas planilhas e os valores reais e por ai vai.

Fugindo rapidamente para outro tópico, eu como desenvolvedor sempre quis embarcar em grande projeto pessoal. Comecei alguns que não levei ao fim, quando chegavam a uma complexidade maior, a dificuldade em gestão e organização (por mais que seja apenas eu fazendo) me levava a engaveta-los. Eu sempre ia direto para a fase de desenvolvimento, pensando nos requisitos enquanto codificava e eu sempre me perdia.

Então esses são os dois grandes motivadores para eu iniciar esse projeto, a vontade de aprimorar meu controle de finanças pessoais e de construir um projeto de software como estudo e portfolio. Essa é uma grande oportunidade de demonstrar minhas capacidades como desenvolvedor e de aprender um pouco sobre a área dos meus outros colegas de profissão como designers de UI, tester, PMs, etc.

Gostaria de comentar sobre as decisões que eu farei ao longo do projeto, algumas delas serão guiadas por meu interesse em aprender determinadas tecnologias, seja para aprofundar em stacks que eu ja atuo ou aprender mais sobre algumas tecnologias que são populares no mercado de trabalho hoje. Existem também restrições financeiras. Não utilizarei ferramental pago no desenvolvimento (por se tratar de um projeto aberto a comunidade existem diversas opções gratuitas para esse fim). Pretendo ser o único usuário da aplicação, por isso a infraestrutura será enxuta e barata afinal, se a proposta é controle financeiro, não faz sentido gastar muito para manter o app rodando.

Por fim algumas decisões poderão parecer conflitantes, a todo momento tentarei ser racional e sensato nas escolhas aplicadas, ao mesmo tempo tentarei fazer escolhas que façam da solução final escalável por ser algo muito importante para o mercado de trabalho, hoje trabalho com um ambiente com uma considerável volumetria de requisições e quero aprimorar meus conhecimentos sobre escalabilidade e system design.