Motivação
Queria validar na prática até onde ferramentas de IA conseguem acelerar a criação de um produto real — sem gastar semanas em setup, arquitetura ou decisões de stack.
A ideia era simples: construir um MicroSaaS funcional, com potencial de uso real, e ver o que aparecia no caminho. Foi assim que surgiu o Linklystics.
O que foi construído
O Linklystics é uma plataforma de centralização e rastreamento de links, voltada para quem trabalha com link na bio, campanhas ou programas de afiliados.
A proposta central: entender quais links performam melhor, medir engajamento e tomar decisões baseadas em dados — em vez de operar no escuro.
A distinção que mais importou durante a concepção:
- ❌ Encurtador de link
- ✅ Plataforma de análise de performance de links
Evitar o genérico foi o desafio mais real do projeto.
Stack e abordagem
O projeto foi construído com Lovable — uma ferramenta de desenvolvimento assistido por IA que combina geração de frontend, backend e lógica de produto em ciclos rápidos.
O ganho imediato foi sair do modo “preciso configurar tudo antes de começar” e entrar no modo “o que precisa funcionar hoje?”. O resultado foi um MVP publicado e funcional em poucos dias, com iteração baseada em uso real desde o início.
Aprendizados
Problema vem antes da tecnologia
A escolha de stack costuma dominar as primeiras horas de um projeto novo. Nesse experimento, ela foi deliberadamente ignorada. O foco foi: existe um problema real aqui? Alguém pagaria por isso? A tecnologia foi consequência, não ponto de partida.
Velocidade é vantagem competitiva
Com IA no processo, o ciclo ideia → MVP → feedback comprime de semanas para dias. Isso muda a lógica de validação: em vez de apostar meses num produto que pode não ter aderência, é possível testar, errar e ajustar com custo baixo.
Produto é mais importante que código
O valor entregue ao usuário não depende da elegância da arquitetura. Depende de utilidade, clareza de proposta e facilidade de uso. Código bem escrito importa — mas vem depois de saber o que construir.
O custo oculto dos prompts técnicos
Uma percepção que ficou durante o processo: quanto mais técnico e detalhado o prompt, maior o consumo de tokens. Em ferramentas como o Lovable, isso se traduz em uma pressão real — a sensação de que o plano vai acabar antes do produto ficar pronto.
Não tenho clareza total sobre como a economia de tokens funciona internamente nessas plataformas, mas a percepção prática foi clara: prompts mais específicos e estruturados consomem significativamente mais do que prompts simples, o que cria uma tensão entre qualidade técnica da instrução e o limite do plano contratado.
Lovable é uma ferramenta para não-técnicos — e isso tem um preço
Antes de falar sobre minha experiência, vale contextualizar o cenário: o conceito de vibe coding — desenvolver produtos guiado por prompts e intuição, sem necessariamente entender o que está sendo gerado — está em alta. Vale assistir esse vídeo que aborda bem essa tendência:
👉 https://youtu.be/4DzMbBYXa7M
Depois de usar o Lovable, ficou evidente para quem é o produto: pessoas sem background técnico, que querem ver algo funcionar na tela com o menor atrito possível.
O problema é que esse posicionamento tem consequências que o usuário leigo dificilmente percebe:
- A IA prioriza aparência e experiência visual — telas bonitas, fluxos que impressionam
- Questões como segurança, estabilidade e boas práticas de arquitetura ficam em segundo plano
- O token é gasto em fazer o produto parecer completo, não necessariamente em fazê-lo ser sólido
Para quem tem conhecimento técnico, essa lacuna aparece cedo. Para quem não tem, o produto parece ótimo — até o momento em que algo quebra em produção ou uma vulnerabilidade aparece.
Lovable entrega satisfação imediata. Entregar um produto confiável é responsabilidade de quem o está construindo.
Vulnerabilidade encontrada em aplicação gerada pelo Lovable
Para além da percepção subjetiva, fiz um teste prático de segurança em uma aplicação construída via vibe coding na plataforma Lovable. O resultado foi direto ao ponto.
Ausência de Content-Security-Policy (CSP)
A aplicação não implementava nenhum cabeçalho Content-Security-Policy.
O CSP é o mecanismo primário de defesa em profundidade contra ataques de Cross-Site Scripting (XSS) e injeção de conteúdo. Sua ausência significa que qualquer conteúdo — scripts, frames, estilos, imagens — pode ser carregado de qualquer origem pelo navegador da vítima, sem restrição alguma.
Na prática, isso abre espaço para:
| Vetor | Impacto |
|---|---|
| XSS refletido ou armazenado | Execução de scripts maliciosos no contexto do usuário autenticado |
| Injeção de frames externos | Clickjacking e roubo de credenciais |
| Carregamento de scripts de terceiros | Exfiltração de dados sem rastreamento |
| Injeção de estilos | Manipulação visual da interface para engenharia social |
Esse tipo de vulnerabilidade não é difícil de mitigar — um cabeçalho HTTP bem configurado resolve. Mas exige que o desenvolvedor saiba que ela existe, entenda o risco e tome a decisão de implementar. Uma IA focada em entregar telas funcionais rapidamente não vai fazer esse julgamento sozinha.
Código que passa no olho não é código seguro. Aparência de produto não é segurança de produto.
Status atual
| Item | Status |
|---|---|
| MVP | Publicado e funcional |
| Validação | Em andamento |
| Evolução | Baseada em uso real |
Próximos passos
- Refinar UX com base nos primeiros usuários
- Adicionar métricas mais avançadas de engajamento
- Explorar modelo de monetização
Conclusão
Esse experimento deixou duas coisas claras:
Nunca foi tão rápido criar um produto digital.
Saber o que construir continua sendo mais difícil — e mais importante — do que saber como construir.
E uma terceira, que ficou evidente no teste de segurança:
Velocidade sem consciência técnica produz produtos frágeis com boa aparência.