Nesse final de semana decidi dar um upgrade no meu website e em poucas horas fui capaz de me repaginar a identidade visual utilizando Lovable.

Bonito, estruturado, com vídeo no hero gerado por IA — e sem escrever CSS na mão.

Mas antes de chegar lá, precisei resolver um problema que a maioria ignora no vibe coding:

Sem estrutura, você produz rápido. E refatora o dobro depois.

Aqui está o que aprendi usando Lovable desde agosto 2025, e o template que criei para nunca mais começar do zero.

A armadilha do vibe coding sem framework

O Lovable é incrível. Você descreve o que quer, ele gera. Em minutos você tem algo visual funcionando.

O problema aparece no prompt 5 sem ter definido cores, fontes, arquitetura de pastas, padrões de código. O Lovable começa a tomar decisões por você — e nem sempre as mesmas em cada prompt.
Resultado: cores hardcoded espalhadas, componentes duplicados, estrutura que ninguém mantém.

A solução não é usar menos IA. É entrar com mais contexto.

Defina antes de gerar — 3 perguntas obrigatórias

1. Product — O quê e para quem? Problema, público, North Star.
2. Design System — Como vai parecer? Tokens HSL, tipografia, componentes. Tudo antes de criar qualquer tela.
3. System Design — Como vai funcionar por baixo? Stack, arquitetura, banco, deploy.
   São coisas diferentes. A confusão entre elas é um dos erros mais comuns.

Design System ≠ System Design

Design System é o vocabulário visual: tokens de cor, tipografia, componentes reutilizáveis. O como parece.
System Design é a arquitetura técnica: como o banco conecta com o frontend, como os módulos se comunicam. O como funciona.

No meu site:
→ Design System: tokens HSL, fontes Plus Jakarta Sans + Inter, variantes de Button e Badge via CVA, glassmorphism e gradient text.
→ System Design: React 18 + Vite + Supabase, feature-based architecture, Event Bus, Ports & Adapters.

Por que NÃO usei microservices???

Lovable + Supabase é um monolito modular, e essa é a decisão certa.
Microservices resolvem problemas de escala operacional para múltiplos times com deploys independentes. Para um SaaS early-stage ou site pessoal, eles adicionam complexidade sem retorno nenhum: service discovery, network latency, infraestrutura de orquestração.

O que importa aqui é ter módulos bem isolados dentro do mesmo processo. Isso é o que feature-based architecture + Event Bus entrega — benefícios de separação de responsabilidades sem a complexidade operacional.

Regra que uso: features nunca importam entre si diretamente. Comunicação via Event Bus tipado. Integrações externas via Ports & Adapters.

SOLID no contexto React — na prática

→ S: um componente faz uma coisa. SectionHeader só renderiza header.
→ O: extensão via CVA variants. Novo estilo de botão? Adiciono uma variant. Não toco no button.tsx.
→ L: Ports & Adapters garante substituição. Troco Supabase Storage por Cloudinary mudando um adapter.
→ I: hooks granulares — useAuth, useOrganization, useFeatureGate. Nada de um useApp() que faz tudo.
→ D: features dependem de interfaces, não do Supabase diretamente.

O vídeo do hero? Gerado com IA também

O background do hero é um vídeo criado com PixVerse (app.pixverse.ai), text-to-video com estilo futurista/tech, exportado como .mp4 e usado com “video autoPlay muted loop” com overlay para garantir legibilidade.

Visual cinematográfico sem banco de imagens, sem designer, sem Adobe Premiere.

O resultado

→ Site: raphaelmoraes.dev
→ Stack: React 18 + Vite + Tailwind + shadcn/ui + Supabase + Cloudflare + PixVerse

→ Tempo: poucas horas de vibe coding estruturado
Documentei tudo num Playbook de 8 prompts prontos para colar no Lovable, com Design System completo, tokens reais do repositório, traduções pt-BR + en, checklists SOLID e regras transversais.

🔗 Site: https://raphaelmoraes.dev

📄 Playbook completo (Gist): https://gist.github.com/rdemoraes/e08d7318de3e3aa0e4c67d69fa1d0fa3

🎬 Vídeo hero gerado com: https://app.pixverse.ai

Lovable #VibeCoding #WebDevelopment #React #Supabase #DesignSystem #SystemDesign #SOLID #AI #GenerativeAI #PlatformEngineering