Projeto paralelo
Connect Auto
Construindo uma plataforma SaaS para garagistas e revendas de veículos.
- Atuação
- Cofundador & Full Stack Software Engineer
- Período
- 2026 — atual
- Tipo
- Projeto paralelo
- Status
- Em desenvolvimento
- Next.js
- React
- TypeScript
- NestJS
- Prisma
- PostgreSQL
- React Query
- Zustand
- TanStack Table
- Tailwind CSS
- Docker
01 / Visão geral
A Connect Auto é uma plataforma SaaS para garagistas e revendas de veículos. O produto reúne CRM, estoque, atendimento, propostas, reservas, vendas, tarefas, calendário e o site público da revenda em um único sistema.
É um projeto paralelo que estou construindo como cofundador e engenheiro. Meu trabalho cobre fluxos de produto, arquitetura de Front-end, interface, integração com API, entendimento do domínio, parte do back-end com NestJS e decisões de produto. A plataforma ainda está em desenvolvimento.
02 / Contexto
O contexto.
A operação de uma revenda costuma ficar espalhada entre planilhas, conversas no WhatsApp e sistemas desconectados.
O produto está sendo desenhado em torno desses fluxos reais: como um lead chega, como um veículo é reservado, como uma proposta é criada e como a negociação caminha pelo funil de vendas.
03 / Desafio
O desafio.
O difícil não é desenhar telas. É traduzir os fluxos da revenda em regras que continuem consistentes entre CRM, estoque, reservas, propostas e vendas.
A interface também precisa lidar com permissões, distribuição de conversas, formulários complexos e um Kanban cujos movimentos dependem de regras de negócio — e não de arrastar livremente.
Fluxo
- 01Novo lead
- 02Primeiro contato
- 03Em andamento
- 04Interesse confirmado
- 05Visita / Test drive
- 06Proposta
- 07Negociação
- 08Venda / Perdido
Uma visão simplificada do funil — não o CRM completo.
04 / Atuação
Minha atuação.
Como cofundador e engenheiro, participo das decisões de produto antes de implementar a interface.
Meu trabalho principal está na arquitetura de Front-end e na UI, além de integrar APIs e contribuir com partes do back-end em NestJS quando a feature atravessa essa fronteira.
05 / O que desenvolvi
O que desenvolvi.
Funil de CRM
Modelar etapas, responsabilidade e as regras que movem um lead pelo funil, incluindo um Kanban com drag-and-drop que precisa respeitar essas regras.
Estoque e reservas
Manter disponibilidade, reservas e propostas alinhadas para a interface não prometer uma unidade que o domínio não pode vender.
Distribuição de atendimento
Encaminhar conversas e tarefas pela equipe, com permissões que mudam o que cada pessoa pode ver e fazer.
Formulários complexos
Propostas, dados do veículo e cadastro de clientes — campos reutilizáveis e validação, em vez de telas isoladas.
Arquitetura de Front-end
Modelo de componentes, primitivas de tabela e uma separação clara entre server state e client state à medida que o produto cresce.
Site público da revenda
Uma vitrine pública do estoque, alimentada pelo mesmo domínio do produto interno.
Estado
Server state
React Query
Dados remotos e cache
- Leads
- Veículos
- Tarefas
- Pipeline
- Reservas
Client state
Zustand
UI state compartilhado
- Filtros
- Rascunhos
- Painéis abertos
- Kanban UI
- Estado local do fluxo
Uma separação conceitual usada no Front-end — não a arquitetura completa do sistema.
06 / Engenharia
Decisões que eu manteria.
Server state e client state resolvem problemas diferentes
O React Query cuida dos dados remotos e do cache, enquanto o Zustand cuida do estado compartilhado da UI — filtros, rascunhos e comportamento da interface. Separar essas responsabilidades deixa sincronização e invalidação mais fáceis de raciocinar.
O funil é um domínio, não só uma lista de colunas
O Kanban representa regras de negócio. Um lead nem sempre pode se mover livremente se estoque, permissões ou reserva dizem o contrário. As colunas são a interface. As regras por trás delas são o domínio.
Reutilizar padrões, não páginas inteiras
Tabelas, formulários, validação e permissões aparecem em vários módulos. Prefiro primitivas reutilizáveis para esses padrões recorrentes em vez de forçar páginas diferentes na mesma abstração.
07 / Stack
- Next.js
- React
- TypeScript
- NestJS
- Prisma
- PostgreSQL
- React Query
- Zustand
- TanStack Table
- Tailwind CSS
- Docker
08 / Impacto
O que já posso defender.
O produto ainda está em desenvolvimento. Ainda não há métricas de produção para compartilhar.
O trabalho até agora tem sido acertar o domínio, a arquitetura e os fluxos centrais antes de falar em escala.
09 / Aprendizados
O que aprendi com esse trabalho.
Se o funil não está claro, o Kanban também não estará. O domínio precisa ser definido antes da interface.
A maior parte dos bugs nesse tipo de produto é bug de estado. Separar server state e client state deixa a UI mais fácil de mudar.