LOTD
Como construí sozinha, do zero ao deploy, um webapp (LOTD - Look of the day) pra montar combinações de roupas durante uma viagem, usando IA como par de desenvolvimento.
O cenário
Sempre quis experimentar desenvolver um produto de ponta a ponta (design, código, deploy) sem depender de um dev. Com IAs generativas hoje conseguindo escrever código real, decidi testar até onde eu conseguiria ir sozinha, usando um problema pessoal como pretexto pra aprender.
O problema que eu tinha? adoro montar looks! Em viagens, o que mais tenho dificuldade é como otimizar a quantidade de peças que levo na mala. Preciso sempre me esforçar para combinar poucas peças, de formas diferentes, pra diferentes situações da viagem. Já tentei planejar tudo antes de viajar, com listas de peças e possíveis combinações (cansativo) ou improvisar no quarto do hotel (ineficiente). Então, queria algo no meio do caminho: um app onde eu cadastrasse as peças da mala e pudesse navegar visualmente pelas combinações possíveis.
Com isso, meu objetivo era aprender, na prática, a desenvolver um produto completo usando IA como ferramenta de programação. Os critérios de sucesso eram pessoais, não de mercado:
-
Conseguir levar uma ideia até um produto funcionando, sozinha
-
Entender as limitações reais de codar com IA (até onde dá, onde trava)
-
Ter algo bom o suficiente pra eu mesma usar na próxima viagem (dentro de 20 dias)
O processo
1. Organizar o contexto
Antes de começar a codar, montei um projeto no Claude dedicado ao LOTD. Comecei alimentando ele com o básico: contexto em markdown de quem eu sou e o conceito do app: o que ele deveria fazer, pra quem, em que situações. Conforme o projeto foi tomando forma, fui iterando os documentos do projeto: o HTML atual sempre atualizado, o design system, decisões tomadas, estrutura de dados.
Isso fez com que cada nova conversa já começasse com a IA sabendo onde a gente parou, sem precisar reexplicar decisões, paleta ou estrutura toda hora. Investir nesse setup no começo agilizou todas as iterações seguintes.
2. Stack e escolhas técnicas
Optei pela stack mais simples possível pra reduzir variáveis e focar na velocidade:
-
HTML único com CSS e JS inline: sem frameworks, sem build, sem dependências
-
localStorage pra persistência: sem backend, sem banco de dados
-
GitHub Pages pra deploy: grátis, manual, suficiente
-
Claude como par de desenvolvimento: eu descrevia o que queria, ele escrevia o código, eu testava e iterava
Essa stack me forçou a entender o que cada pedaço fazia. Sem abstrações, cada decisão era visível e editável.
3. Tirar do papel
Comecei enviando para o Claude um wireframe do fluxo principal: cadastrar peça → criar look → favoritar. A primeira versão funcional ficou pronta em poucas horas. Não tinha o melhor dos visuais, mas funcionava: eu já conseguia tirar foto de uma peça, classificar e ver combinações.
Daqui já vem o primeiro aprendizado: começar com algo funcionando destrava as decisões seguintes. É muito mais fácil saber se um botão tá no lugar certo quando você consegue clicar neles.
4. Resolver os atritos de uso
Testando comigo mesma, várias coisas incomodavam:
-
Navegação entre peças era só com setas, então adicionei drag/swipe horizontal
-
Sobreposição (cardigã, jaqueta) não cabia no modelo de 3 categorias, então criei uma flag isOverlay pra peças "parte de cima" que funcionam como camada extra opcional
-
Favoritos como stack de fotos sobrepostas estilo polaroid não facilitavam a visibilidade das peças e ajudavam pouco na hora de escolher um look.
E aqui vem outro aprendizado: o design system foi se firmando pelo uso, não somente pelo plano. Cada atrito real virou uma decisão.
5. Limites do "sem backend"
Por uma questão visual, e para facilitar a imaginação de um look com várias peças, tentei adicionar remoção automática de fundo nas fotos das peças. Foi onde primeiro bati num limite real: as APIs disponíveis (Clipdrop, remove.bg) bloqueiam requisições do GitHub Pages por CORS, e a opção gratuita do remove.bg não escala. A solução seria subir um backend só pra fazer proxy, uma complexidade que não fazia sentido pro estágio do projeto.
Como aqui estamos falando de algo anterior à um MVP, decidi fazer a remoção do fundo das fotos de forma manual e testar o mais breve possível as funções básicas no dia-a-dia
Aprendizado: nem toda evolução vale resolver agora. Postergar com clareza é uma decisão de produto.
Principais aprendizados
1. Velocidade muda como você decide
Descrever uma mudança e ver o código pronto encurta o ciclo a ponto de mudar como você decide o que construir. Você experimenta mais porque experimentar custa menos, e isso fez com que decisões de design e produto fossem validadas testando, não discutindo. Escrever prompts específicos ("adicione swipe horizontal nos slots usando touchstart/touchmove") também me fez entender o código que recebia: não virei dev, mas saí sabendo ler e editar JS com confiança.
2. Manter contexto é parte do trabalho
Saber o que mostrar pra IA, em que ordem, e o que omitir, virou uma habilidade em si. Sem isso, ela perde o fio da meada e o código começa a desfazer decisões anteriores. Manter um arquivo de contexto vivo, com decisões, design system, estrutura e funções, fez com que cada nova conversa começasse de onde a anterior parou. Investir nesse setup no início refletiu em todas as iterações seguintes.
3. A IA executa, mas as decisões continuam suas
Ela escreve o código, mas o que construir, como priorizar e quando parar continuou sendo meu trabalho. As restrições do ambiente (CORS, localStorage, GitHub Pages) só apareceram testando de verdade, e saber identificá-las foi o que separou ideias possíveis de ideias caras. Postergar a remoção de fundo, por exemplo, foi uma decisão de produto que a IA não tomaria por mim.
O LOTD hoje
Depois de dias testando e iterando, o webapp ganhou maturidade: a área de favoritos tem pastas e filtros, dá pra nomear cada look, e o app sugere combinações automáticas a partir das peças cadastradas.
Mas a melhor forma de entender se ele funciona de verdade é colocá-lo à prova na vida real.
Estou usando agora pra montar a mala da próxima viagem, e até aqui está cumprindo o papel: cadastro as peças, monto combinações, organizo por pastas de cada cidade e nomeio cada look com o dia que pretendo usar.
Já tenho uma lista de pontos do layout que quero evoluir, mas com a viagem em 9 dias a prioridade é montar a mala, rs. Volto pra refinar depois do teste real: quando os atritos que importam vão aparecer no momento em que o app precisa ser útil.
Próximos passos
Ajustar os atritos que
percebi usando
Pequenos detalhes de UX que só apareceram em contexto real (ordenação, edição rápida, mais flexibilidade nas categorias).
Incorporar feedbacks da viagem e das pessoas
Sair do "funciona pra mim" pra entender se o modelo mental do app faz sentido pra outras pessoas.
Foco em arquiterura
e escala
Avaliar a introdução de um backend pra desbloquear funcionalidades como remoção automática de fundo, e investigar o caminho de publicação em lojas de aplicativos.
Teste e compartilhe suas percepções
Pra ter a experiência completa, adicione o webapp à tela inicial do celular, assim ele abre em tela cheia, com ícone próprio, igualzinho a um app.
No iPhone (Safari):
-
Abra carolpereiraux.github.io no Safari
-
Toque no menu (3 bolinhas no canto inferior direito)
-
Clique em compartilhar e escolha "Adicionar à Tela de Início"
No Android (Chrome):
-
Abra carolpereiraux.github.io no Chrome
-
Toque no menu (3 bolinhas no canto superior direito)
-
Escolha "Adicionar à tela inicial" ou "Instalar app"