4.1 — Concepção e Arquitetura de um Produto de IA do Zero (Product Design)

Dia 1: Definir problema + persona

  - Quem exatamente tem esse problema?

  - Qual a dor concreta (não "seria legal ter")?

  - Quanto tempo/dinheiro essa dor custa hoje?



Dia 2-3: Protótipo de papel + entrevistas

  - 5 entrevistas com a persona alvo

  - Não mostrar produto — descrever o problema e observar reação

  - Se alguém perguntar "quando posso usar?" → sinal positivo



Dia 4-5: Landing page + lista de espera

  - Descreve o produto que você vai construir

  - Botão "Quero acesso" com captura de email

  - 50+ emails = validação suficiente para construir MVP



Dia 6-7: Analisar resultados e decidir

  - Validado: ir para arquitetura

  - Não validado: pivotar (voltar ao dia 1)

Camadas obrigatórias:

  1. Frontend: Angular/React/Next.js + chat UI

  2. API Backend: Express/FastAPI + autenticação

  3. Camada de IA: LLM via API + RAG (se necessário)

  4. Persistência: PostgreSQL (dados de usuário) + vector DB (embeddings)

  5. Infraestrutura: Railway/Render + Netlify/Vercel



Camadas opcionais (não no MVP):

  - Fine-tuning próprio (→ validar primeiro com prompt engineering)

  - Modelo self-hosted (→ só se custo de API for inviável em escala)

  - Microserviços (→ só se o monolito travar)

LLM (geração de texto):

  Buy: sempre no MVP (Anthropic Claude, OpenAI GPT)

  Build (self-hosted): só quando custo > $5k/mês E volume > 10M tokens/dia



Embeddings:

  Buy: OpenAI text-embedding-3-small ($0.00002/1k tokens) → suficiente para MVP

  Build: quando volume > 1B tokens/mês



Vector Database:

  Buy: Pinecone free tier (100k vetores) → suficiente para MVP com <10k docs

  Build-own: pgvector (PostgreSQL extension) → zero custo extra se já usa Postgres



Autenticação:

  Buy: Clerk/Auth0/Supabase Auth → 1 hora de setup vs 2 semanas de implementação

  Build: nunca no MVP



Frontend:

  Build: Angular (você já sabe) → não tem "build vs buy" aqui

  Template: usar biblioteca de UI (Tailwind + shadcn) para acelerar

Entrega 1 — RAG CLI (2 semanas):

  Critério de aceite: indexar 10 documentos, responder 5 perguntas com fonte correta

  Stack: Python + LangChain/manual + ChromaDB + Claude

  Valida: se o RAG funciona para o domínio específico



Entrega 2 — Backend API (2 semanas):

  Critério de aceite: 3 endpoints funcionando (upload, chat, histórico)

  Stack: Express/FastAPI + PostgreSQL + pgvector + Claude

  Valida: se a arquitetura suporta multi-usuário



Entrega 3 — Frontend + Deploy (2 semanas):

  Critério de aceite: usuário externo consegue usar sem ajuda

  Stack: Angular + Netlify + Railway/Render

  Valida: se o produto é utilizável por não-técnicos

def estimar_custo_mensal(

    usuarios_ativos: int,

    consultas_por_usuario_por_dia: float,

    tokens_input: int = 1500,   # contexto + histórico + documento

    tokens_output: int = 500,   # resposta do LLM

    modelo: str = "claude-haiku-4-5-20251001",

):

    PRECOS = {

        "claude-haiku-4-5-20251001": (0.00025, 0.00125),  # input, output por 1k tokens

        "claude-sonnet-4-6": (0.003, 0.015),

    }

    preco_in, preco_out = PRECOS[modelo]

    

    consultas_mes = usuarios_ativos * consultas_por_usuario_por_dia * 30

    custo_mes = consultas_mes * ((tokens_input/1000)*preco_in + (tokens_output/1000)*preco_out)

    

    return {

        "consultas_mes": int(consultas_mes),

        "custo_llm_mes_usd": round(custo_mes, 2),

        "custo_por_usuario_usd": round(custo_mes / usuarios_ativos, 2),

    }



# AssAI Docs: 100 usuários, 20 consultas/dia, haiku

# → 60k consultas/mês, $22.50/mês, $0.23/usuário

# → cobrar R$39/mês → margem bruta: R$28.50/usuário (73%)

Hipótese: advogados perdem 2h/dia procurando cláusulas em contratos antigos

Persona: advogados em escritórios de 2-10 pessoas



Entrevistas (3 de 5 afirmaram):

  "Busco no Word mas os contratos são imagens PDF escaneadas"

  "Às vezes preciso comparar cláusula de rescisão em 40 contratos"

  → Dor real, com frequência alta



Landing page: 73 emails em 48h → VALIDADO



Decisão: construir MVP de RAG para busca em contratos jurídicos

Regra de ouro: 5 entrevistas + landing page antes de escrever código

"Mas eu tenho certeza que as pessoas vão querer" → certeza ≠ validação

Haiku para MVP → benchmark com conjunto de teste → subir para Sonnet apenas se necessário

Diferença de custo: 12x entre Haiku e Sonnet

Microserviços, Kubernetes, Redis, RabbitMQ → tudo isso DEPOIS de validar

MVP precisa de: API + DB + LLM + Frontend. Ponto.

Fine-tuning custa tempo e dinheiro

Só faz sentido depois de: (1) produto validado, (2) prompt engineering esgotado