Case Study · Produto Próprio
PONTE.IA
“A ponte entre a dor do seu negócio e a IA certa.”
Catálogo setorizado de ferramentas de IA para microempresas do interior, precificado em créditos por uso, sem mensalidade. Um MVP construído para medir demanda real antes de construir as ferramentas de fato.
O Problema
Ferramenta de IA não falta.
Falta a ponte.
Microempresas de uma cidade-polo do interior de SP e região, 21 municípios, vivem dores concretas todos os dias. O que elas não têm é o mapa entre essas dores e a IA que as resolve.
A dor não tem nome de tecnologia
O dono de microempresa não procura “LLM” nem “automação”. Ele tem uma conciliação que não fecha, um contrato sem revisar, um lead esfriando. O mercado apresenta tecnologia; ele precisa de resposta para a dor.
Mensalidade não fecha a conta
Assinar um software por mês para usar de vez em quando não cabe no caixa de uma microempresa. A resistência a mensalidades é parte do problema, e qualquer solução precisa respeitá-la.
Construir antes de validar sai caro
Desenvolver 18 ferramentas de IA de verdade, antes de saber quais têm procura, seria meses de engenharia apostados no escuro. O MVP inverte a ordem: primeiro mede, depois constrói.
A Tese do Produto
Vender a dor resolvida,
não a tecnologia.
Três decisões de produto sustentam o Ponte IA, todas na direção de honestidade e medição.
Dor antes de tecnologia
Cada ferramenta é apresentada pela dor que resolve, não pelo que tem dentro. O catálogo não diz “processamento de linguagem”; diz “bate extrato e lançamentos sem conferência manual”.
Preço transparente, em créditos por uso
Cada uso custa de 30 a 60 créditos, exibidos antes do clique. Sem mensalidade, sem surpresa. No MVP, o saldo de 200 créditos é demonstrativo: conceito exibido, sem compra nem débito real.
Registro de intenção como métrica
Antes de construir cada ferramenta, o MVP mede demanda real: o usuário cria conta e registra a intenção de usar. O que tiver procura de verdade é o que vira produto primeiro.
Demo Interativa
Explore o catálogo real.
Os dados abaixo são o catálogo real do MVP: 6 setores, 18 ferramentas, cada uma com a dor que resolve e o custo em créditos. Navegue por setor e registre intenções, exatamente a mecânica do produto.
Engenharia
Um MVP que não precisa
ser jogado fora.
As decisões de arquitetura foram tomadas para o produto crescer sem reescrita, os contratos de hoje já são os da fase seguinte.
Contratos prontos para migrar
As APIs foram desenhadas para trocar o mock por Supabase (auth, Postgres, RLS) sem reescrever nenhuma tela: useAuth() mantém a assinatura ao trocar localStorage por supabase.auth, intenções viram tabela Postgres com RLS mantendo a mesma API, e o repositório de catálogo em JSON vira consulta Postgres com as mesmas assinaturas.
Escrita atômica, com fila
A persistência do catálogo em JSON grava primeiro num arquivo temporário e depois faz rename, o arquivo nunca fica corrompido no meio de uma escrita. Uma fila de promises serializa as mutações concorrentes do painel admin.
Client-safe vs. server-only
Separação estrita entre o que pode ir ao browser e o que não pode: o módulo de tipos e ícones é importável no client; o módulo de dados é server-only, com um guard que lança erro se for importado no browser.
Server Actions com validação no servidor
O admin segue o padrão useActionState, (prevState, formData) → ActionState, com validação de entrada no servidor e revalidação da árvore de rotas após cada mutação. O código documenta explicitamente que o gate admin client-side não é segurança real: na fase Supabase, vira role verificada no servidor com RLS.
SSG e SEO por rota
generateStaticParams e generateMetadata por setor e por ferramenta: cada página do catálogo nasce estática e indexável. E os slugs são estáveis por design, renomear um setor não quebra links nem intenções já registradas.
Design system com regra de copy honesta
A spec de design é fonte de verdade: tokens CSS obrigatórios, hex proibido no JSX e acessibilidade AA especificada, contrastes mínimos, foco visível, aria-live. E uma regra de produto: os números da vitrine derivam do catálogo real. Sem depoimentos inventados, sem métricas de fachada.
Stack
Construído no stack
mais recente do React.
Cada escolha do stack aparece no código do MVP, nada de lista decorativa.
Next.js 16
App Router · RSC · Server Actions
React 19
useActionState · Suspense
TypeScript 5
Tipagem estrita de ponta a ponta
Tailwind 4
Tokens via CSS variables
shadcn · Base UI
Componentes acessíveis
Estado Atual
Navegável de ponta a ponta,
medindo demanda.
O MVP está completo como experiência: landing, catálogo por setor, página por ferramenta, conta, registro de intenção e painel admin com CRUD do catálogo sem redeploy. Agora ele cumpre seu papel: validar demanda real em uma cidade-polo do interior de SP e região, 21 municípios. O que tiver procura de verdade define o que será construído primeiro.