CadVision
SaaS de gestão de catálogo para e-commerce que extrai, enriquece e sincroniza dados de produtos com inteligência artificial.
- Para quem
- Produto próprio, em operação com contas de clientes
- Ano e andamento
- 2026 · publicado
O ponto de partida
Cadastrar produto em e-commerce é trabalho repetitivo: copiar dados de nota fiscal ou foto, padronizar descrição, classificar, e repetir tudo em cada canal de venda. Quem tem catálogo grande gasta horas por semana nisso, e o erro de digitação vira produto errado na loja.
O que foi construído
SaaS multi-tenant que lê produtos de imagem, planilha e nota fiscal eletrônica, usa visão computacional e um modelo de linguagem para extrair e enriquecer os campos, e sincroniza o resultado com as plataformas de venda. A IA propõe, a pessoa valida, e só então o dado sai para o canal.
O produto em uso
As principais telas e o que a pessoa pode fazer em cada uma. Selecione uma captura para ampliar.
- Ampliar captura em uma nova aba
Catálogo: busca, filtros, dados e ações em um painel de trabalho. - Ampliar captura em uma nova aba
Edição: imagem e campos do produto reunidos para revisão antes da publicação.
Minha participação
Produto, arquitetura full-stack, IA e infraestrutura
Decisões importantes
- Separar organizações e permissões com uma arquitetura multi-tenant.
- Usar IA como etapa assistida do cadastro, mantendo validação antes da sincronização.
- Distribuir frontend, backend e dados em serviços independentes com deploy contínuo.
O que funcionou
- O fluxo reduz etapas manuais entre a entrada de dados e a publicação do catálogo.
- A arquitetura permite integrar serviços brasileiros de e-commerce, pagamento e documentos fiscais.
Limites atuais
- O acesso ao produto exige uma conta e algumas integrações dependem de credenciais do cliente.
- O repositório é privado e será apresentado apenas por evidências públicas e descrição do case.
Próximo passo
Aprimorar a validação em lote, ampliar integrações e documentar resultados de uso em operações reais.
Por dentro da construção
Arquitetura, tecnologias e as escolhas de implementação deste projeto.
- FastAPI
- Supabase
- Gemini
- Multi-tenancy
- Railway
Como o sistema é montado
Frontend, API e dados em serviços independentes, com as três camadas do backend separadas por responsabilidade: rota não conhece banco, serviço não conhece HTTP. Cada organização é isolada por regra no próprio Postgres, não por filtro na aplicação.
Frontend
Vercel- HTML, CSS e JavaScript sem framework
- Configuração por ambiente
- Painel de catálogo e integrações
Sem framework de interface por escolha: menos build, menos dependência, deploy trivial.
REST em JSON
API
Railway, FastAPI e Python 3.11- api/routes, camada HTTP
- services, regra de negócio
- repositories, acesso a dados
- core, config e segurança
Assíncrona de ponta a ponta, com limite de requisição e tarefas agendadas de cobrança.
Chamadas assíncronas
Dados e serviços
Supabase e provedores externos- Postgres com RLS por organização
- Google Vision e Gemini
- Stripe e AbacatePay
- Bling, WooCommerce e Nuvemshop
O isolamento entre clientes é garantido pelo banco, não pela camada de aplicação.
Stack e o porquê de cada peça
Backend
- FastAPI e Python 3.11
- IO assíncrono para chamadas de IA e integração
- SQLModel
- Um modelo só para ORM e validação
- APScheduler
- Ciclos de cobrança e sincronização agendada
- pytest
- Cobertura nas rotas que movem dinheiro e dados
Inteligência
- Google Vision
- Leitura de imagem e documento fiscal
- Gemini via LangChain
- Extração e padronização dos campos
- sentence-transformers e ChromaDB
- Busca semântica no catálogo
Dados e infraestrutura
- Supabase Postgres com RLS
- Multi-tenancy garantido no banco
- Railway e Vercel
- Backend e frontend com deploy independente
- Stripe e AbacatePay
- Assinatura internacional e meio local