Eu só queria apresentar melhor meus projetos.
Acabei construindo uma ferramenta inteira para isso.
Quem trabalha com produto sabe que terminar a aplicação não encerra o trabalho.
Ainda existe uma etapa que costuma ser tratada como detalhe: mostrar o que foi construído.
Uma boa interface pode parecer comum dentro de um screenshot solto. Um projeto com meses de decisões pode virar apenas mais um retângulo perdido em uma página de portfólio.
O produto existe.
Mas a apresentação ainda não conta a história dele.
Foi desse incômodo que nasceu o Framecraft.
O problema não era criar mockups
Ferramentas para mockups já existem.
Algumas são excelentes.
O problema aparecia quando eu tentava encaixá-las no meu processo.
Marca-d’água no resultado. Recursos importantes bloqueados. Pouco controle sobre a composição. Assinaturas difíceis de justificar para uma tarefa que eu não realizava todos os dias.
Eu conseguia criar uma imagem.
Mas não conseguia criar exatamente a apresentação que tinha imaginado.
Essa diferença importa.
Quando você está apresentando um projeto autoral, cada escolha comunica alguma coisa: perspectiva, fundo, dispositivo, proporção, tipografia, profundidade e até o espaço vazio ao redor da interface.
Se a ferramenta limita essas decisões, o resultado começa a carregar mais a identidade dela do que a sua.
A primeira decisão foi construir para mim
O Framecraft não começou como uma ideia de SaaS.
Começou como uma ferramenta que eu queria usar.
O objetivo inicial era simples: enviar um screenshot, posicioná-lo em uma composição e exportar uma imagem pronta para o meu portfólio.
Desktop primeiro.
Depois tablet e celular.
Em seguida vieram os controles de perspectiva, escala, rotação, sombra, desfoque, moldura de navegador e diferentes proporções de canvas.
Cada nova função surgiu da mesma pergunta:
isso me ajuda a apresentar melhor um projeto real?
Esse filtro evitou que o editor virasse apenas uma coleção de controles.
Ferramentas criativas não precisam oferecer tudo.
Precisam tornar as decisões certas mais fáceis.
Quando um editor deixa de ser uma tela
Em determinado momento, salvar apenas o estado atual já não era suficiente.
Eu precisava voltar a uma composição.
Duplicar uma ideia.
Testar outra proporção sem perder a anterior.
Renomear projetos. Organizar versões. Continuar de onde havia parado.
Foi quando o Framecraft deixou de ser uma tela de edição e começou a se comportar como produto.
Criei uma biblioteca de projetos locais usando IndexedDB. As composições passaram a ser salvas automaticamente no navegador, sem exigir conta, banco de dados ou configuração inicial.
Essa decisão parece pequena, mas define muito da experiência.
O usuário entra e cria.
Não existe cadastro interrompendo o primeiro contato. Não existe infraestrutura remota para justificar antes de existir valor.
Primeiro, a ferramenta prova que é útil.
Depois, ela pode pedir mais.
Controle visual sem transformar tudo em complexidade
Conforme usei o editor, outra necessidade ficou evidente: o screenshot não deveria ser o único elemento da composição.
Adicionei textos personalizados, stickers nativos e upload de adesivos próprios. Depois vieram posicionamento, rotação, opacidade, fontes, pesos, alinhamento, cores e organização por camadas.
Os elementos podem ser bloqueados, ocultados, duplicados e reorganizados.
Guias magnéticas ajudam a encontrar o centro do canvas.
Atalhos tornam o fluxo mais próximo de uma ferramenta visual de verdade.
Até os dialogs padrão do navegador foram substituídos.
Não porque um alert() deixaria a aplicação inutilizável.
Mas porque produtos perdem coerência nos lugares em que paramos de decidir.
Se a interface tem uma linguagem própria, uma confirmação de exclusão também faz parte dela.
Templates não deveriam apagar autoria
Templates podem acelerar o trabalho.
Também podem fazer tudo parecer igual.
Por isso, a biblioteca inicial do Framecraft não entrega peças fechadas. Ela entrega pontos de partida.
Cada template combina proporção, dispositivo, fundo, perspectiva, elementos e direção visual, mas preserva a imagem atual e mantém todas as decisões editáveis.
O template reduz o tempo até a primeira boa composição.
Ele não encerra o processo criativo.
Essa distinção é importante para qualquer ferramenta que prometa velocidade: acelerar não pode significar retirar controle.
Exportar também é uma decisão de produto
Uma imagem para o portfólio não tem as mesmas necessidades de um post quadrado.
Um story não tem a mesma proporção de uma capa horizontal.
Por isso, a exportação evoluiu para suportar resoluções em 1x, 2x e 3x, além de formatos rápidos para apresentações e redes sociais.
O objetivo não era apenas gerar um PNG.
Era reduzir o caminho entre terminar a composição e realmente publicá-la.
Quanto menor esse caminho, maior a chance de o trabalho sair do editor e chegar ao mundo.
A stack foi consequência do produto
O Framecraft foi construído com Next.js, React, TypeScript, Tailwind CSS e Zustand.
Os projetos vivem localmente em IndexedDB. A exportação transforma o canvas em uma imagem de alta resolução no próprio navegador.
Mas a parte mais interessante não foi escolher a stack.
Foi decidir o que ainda não precisava existir.
Sem autenticação na primeira versão.
Sem banco remoto.
Sem cobrança.
Sem uma arquitetura desenhada para milhões de usuários antes do primeiro uso real.
A tecnologia sustentou o estágio do produto em vez de tentar antecipar todos os estágios futuros.
Isso torna a base simples hoje e ainda deixa um caminho claro para sincronização na nuvem, contas, planos e colaboração amanhã.
Construir para si não significa construir sem rigor
Projetos pessoais costumam receber uma permissão perigosa: a de permanecer improvisados.
Como não existe cliente cobrando, algumas decisões são adiadas indefinidamente.
No Framecraft, tentei seguir na direção oposta.
Estados vazios, feedback de salvamento, erros de armazenamento, compatibilidade com projetos anteriores, acessibilidade dos dialogs, migração de novos campos e build de produção fizeram parte do trabalho.
Não porque tudo precisava nascer perfeito.
Mas porque existe diferença entre uma primeira versão pequena e uma primeira versão descuidada.
Escopo reduzido não precisa significar qualidade reduzida.
Talvez isso vire um micro SaaS
Hoje, o Framecraft resolve primeiro um problema meu.
E isso já é suficiente para justificar sua existência.
Mas a estrutura aponta para algo maior.
Projetos na nuvem. Templates compartilháveis. Kits de marca. Histórico de versões. Exportações em lote. Planos para criadores e equipes.
Essas possibilidades existem.
Só não precisam ser construídas antes de sabermos quais delas realmente importam.
Transformar uma ferramenta pessoal em produto não significa adicionar cobrança a tudo.
Significa descobrir se o problema também pertence a outras pessoas, e se a solução cabe no processo delas.
O que ficou dessa construção
O Framecraft começou porque eu não queria continuar adaptando meu trabalho aos limites de outras ferramentas.
Mas construir a própria solução não é sempre a resposta.
Na maioria das vezes, pagar por uma ferramenta pronta continua sendo mais barato do que desenvolver e manter outra.
O ponto é diferente.
Às vezes, uma fricção recorrente encontra exatamente as habilidades, a curiosidade e o momento certo para virar produto.
Quando isso acontece, o incômodo deixa de ser apenas um obstáculo.
Ele vira direção.
Eu só queria imagens melhores para o meu portfólio.
No processo, construí uma nova peça dele.
Compartilhar em:
Sem spam. Só conteúdo que vale abrir.