Catálogo

Execução 24 meses

Roadmap SPEEDSHOP Catálogo de Peças

Plano operacional para construir o SPEEDSHOP como ativo de dados e inteligência técnica, começando pequeno e profundo em motos off-road/enduro.

5fases
24mhorizonte
Dadosprimeiro

Guardrails

Regras que seguram a estratégia no trilho

O recorte inicial permanece motos off-road/enduro.
O maior valor está na confiança dos dados, não no checkout.
Marketplace só deve vir após fitment, fornecedores e qualidade estarem maduros.
A maturidade deve seguir a ordem: dados, uso real, fornecedores/API, escala.
0

0 a 30 dias

Fase 0 - Estratégia e fundação

Definir foco, governança, arquitetura, categorias iniciais, fornecedores prioritários e metodologia de dados.

Escopo

  • Nicho inicial em motos off-road/enduro.
  • Categorias de alto giro: escapamentos, relação, pneus, filtros, óleos, freios e proteções.
  • Regras de fitment, score, auditoria, imagem e fonte.
  • Seleção de 5 a 10 oficinas/lojas validadoras.
  • Seleção de 10 fornecedores iniciais.

Entregáveis

  • PRD final.
  • Modelo de dados v1.
  • Política de dados e publicação.
  • Template de planilha fornecedor.
  • Backlog técnico.
  • Lista de veículos/SKUs prioritários.
  • Protótipo UX navegável ou MVP atual refinado.

Time necessário

  • Founder/COO.
  • CTO/Fullstack senior.
  • Product manager.
  • Especialista catálogo/peças.
  • Designer UX part-time.
  • Consultor jurídico/LGPD part-time.

Dependências

  • Definição do recorte inicial.
  • Acesso a fornecedores/parceiros.
  • Regras de licenciamento de imagens/dados.

Riscos

  • Escopo amplo demais.
  • Dados sem fonte.
  • Falta de parceiros validadores.

Critérios de sucesso

  • Escopo fechado.
  • 500 SKUs candidatos priorizados.
  • 50 veículos/variações priorizados.
  • 5 parceiros validadores confirmados.
  • Regras de governança aprovadas.

KPIs

  • Fornecedores contatados.
  • Parceiros validados.
  • SKUs mapeados.
  • Categorias priorizadas.
  • Fontes permitidas identificadas.

Backlog

  • Definir schema.
  • Definir score.
  • Definir workflows admin.
  • Criar template CSV.
  • Mapear veículos e categorias.
  • Criar plano comercial piloto.

Priorização

  • Dados e governança.
  • Fitment.
  • UX de busca.
  • Backoffice mínimo.

Não fazer

  • Marketplace.
  • API pública.
  • App mobile nativo.
  • Cobertura de todos os veículos.
  • Scraping sem autorização.
1

31 a 90 dias

Fase 1 - MVP técnico e banco inicial

Construir o MVP data-first funcional com banco real, busca, fitment, admin básico e dados fictícios/reais autorizados.

Escopo

  • Next.js PWA.
  • PostgreSQL + Prisma.
  • Auth/RBAC básico.
  • Cadastro de veículos, produtos e fitments.
  • Busca por veículo, part number e OEM.
  • Produto, veículo, comparação e garagem.
  • Importação CSV básica.
  • Upload de imagem com origem/licença.
  • Auditoria.
  • Seed sample e primeiros dados autorizados.

Entregáveis

  • MVP online.
  • Admin básico.
  • Banco inicial.
  • Pipeline CSV.
  • Logs de auditoria.
  • Página de produto.
  • Página por veículo.
  • Feedback serviu/não serviu.
  • Testes do core.

Time necessário

  • 1 CTO/arquiteto.
  • 1 fullstack senior.
  • 1 fullstack pleno.
  • 1 data/catalog analyst.
  • 1 UX/UI part-time.
  • 1 QA part-time.

Dependências

  • Infra local/staging.
  • Definição de schema.
  • Planilhas de fornecedores.
  • Licenças de imagem.

Riscos

  • Banco supercomplexo atrasar MVP.
  • UX ficar pesada.
  • Importação gerar muita sujeira.

Critérios de sucesso

  • Buscar KTM EXC-F 450 2024.
  • Ver categorias e produtos.
  • Ver score, fonte e restrição.
  • Criar fitment aprovado e em análise.
  • Importar CSV com quarentena.
  • Registrar auditoria.

KPIs

  • Tempo de busca.
  • % fitments com fonte.
  • SKUs cadastrados.
  • Veículos cadastrados.
  • Conflitos detectados.
  • Testes passando.
  • Tempo até encontrar peça.

Backlog

  • Schema final MVP.
  • Auth/RBAC.
  • CRUD admin.
  • Fitment engine básico.
  • Search MVP.
  • CSV import.
  • DAM básico.
  • AuditLog.
  • UI mobile-first.

Priorização

  • Banco + fitment.
  • Busca.
  • Admin.
  • Produto/veículo.
  • Feedback.
  • Upload.

Não fazer

  • Pagamento/checkout.
  • Marketplace.
  • OpenSearch/Neo4j.
  • Portal fornecedor completo.
  • IA publicando dados.
2

3 a 6 meses

Fase 2 - Piloto com lojas/oficinas

Validar uso real em balcão/oficina, reduzir erro de venda e melhorar base com feedback de campo.

Escopo

  • 5 a 15 lojas/oficinas piloto.
  • Modo balcão.
  • Modo oficina.
  • Orçamento simples.
  • Feedback de campo.
  • Dashboard de qualidade.
  • Busca sem resultado.
  • Correções rápidas de catálogo.
  • Expansão controlada de SKUs.

Entregáveis

  • Ambiente piloto.
  • Treinamento rápido.
  • Relatórios de uso.
  • Workflow de feedback.
  • Backoffice de revisão melhorado.
  • 2.000 a 5.000 fitments curados.

Time necessário

  • 1 PM.
  • 2 fullstack.
  • 1 data engineer/analyst.
  • 2 catalog analysts.
  • 1 customer success.
  • 1 suporte técnico.

Dependências

  • Usuários reais engajados.
  • Dados suficientes por categoria.
  • Processo de correção rápido.

Riscos

  • Usuário não confiar no score.
  • Baixa adesão no balcão.
  • Feedback chegar desorganizado.
  • Catálogo incompleto frustrar uso.

Critérios de sucesso

  • Balconista encontra peça em segundos.
  • Oficinas enviam feedback.
  • Redução perceptível de erro/devolução.
  • No-result vira backlog acionável.
  • Usuários voltam semanalmente.

KPIs

  • WAU por loja/oficina.
  • Buscas por usuário.
  • Taxa de busca com resultado.
  • Feedbacks recebidos.
  • Fitments corrigidos.
  • Devoluções por incompatibilidade.
  • Tempo médio de atendimento.
  • NPS piloto.

Backlog

  • Orçamento.
  • Garagem.
  • Feedback com foto.
  • No-result queue.
  • Melhor comparação.
  • Relatórios por loja.
  • Correções de UX mobile.
  • Treinamento/onboarding.

Priorização

  • Uso real.
  • Qualidade da base.
  • Velocidade de balcão.
  • Relatórios piloto.

Não fazer

  • Abrir para público amplo.
  • Cobrar forte antes de provar valor.
  • Expandir para muitos segmentos.
  • Criar features enterprise.
3

6 a 12 meses

Fase 3 - Portal do fornecedor e API inicial

Transformar fornecedores em fonte contínua de dados e lançar API/widget controlados para parceiros selecionados.

Escopo

  • Portal fornecedor v1.
  • Upload planilhas/imagens/manuais.
  • Pendências de qualidade.
  • Oportunidades por busca sem resultado.
  • API privada v1.
  • Widget veja se serve.
  • Webhooks básicos.
  • Planos comerciais beta.

Entregáveis

  • Portal fornecedor.
  • API docs/OpenAPI.
  • Widget produto.
  • API keys e rate limit.
  • Dashboard fornecedor.
  • Workflow de aprovação fornecedor.
  • Primeiros contratos SaaS/API.

Time necessário

  • 1 PM B2B.
  • 1 tech lead.
  • 2 fullstack.
  • 1 backend/API.
  • 1 data engineer.
  • 2 catalog analysts.
  • 1 partnerships manager.
  • 1 customer success.

Dependências

  • Backoffice maduro.
  • Dados suficientes para API ter valor.
  • Fornecedores parceiros.
  • Segurança/API keys.

Riscos

  • Fornecedor enviar dado ruim.
  • API expor dado sensível.
  • Widget gerar carga/abuso.
  • Comercial vender antes da maturidade.

Critérios de sucesso

  • 10 fornecedores ativos.
  • 3 a 5 parceiros usando widget/API.
  • Dados recebidos com melhoria mensurável.
  • API responde com fonte/confiança.
  • Sem publicação automática de fitment crítico.

KPIs

  • Fornecedores ativos.
  • Uploads/mês.
  • % produtos com imagem/manual.
  • Fitments enviados vs aprovados.
  • Chamadas API.
  • Widget checks.
  • Leads gerados.
  • MRR beta.
  • Tempo de aprovação de fornecedor.

Backlog

  • Portal fornecedor.
  • API v1.
  • Widget produto.
  • API logs.
  • Rate limit.
  • Webhooks.
  • Analytics fornecedor.
  • Planos de assinatura.
  • Melhor pipeline importação.

Priorização

  • Portal fornecedor.
  • Qualidade de dados.
  • API/widget privado.
  • Monetização beta.

Não fazer

  • API pública aberta sem contrato.
  • Marketplace aberto.
  • Permitir fornecedor publicar direto.
  • Analytics avançado demais.
4

12 a 24 meses

Fase 4 - Escala e monetização B2B

Escalar a base, monetizar SaaS/API/widget, expandir verticais e criar barreiras competitivas com dados proprietários.

Escopo

  • SaaS para lojas/redes.
  • API paga.
  • Widget white-label.
  • Analytics fornecedor.
  • Expansão big trail, ATV/UTV, e-bike premium, náutica/kart.
  • OpenSearch.
  • Grafo opcional.
  • IA assistida de curadoria.
  • Marketplace controlado, se dados estiverem maduros.

Entregáveis

  • Planos comerciais oficiais.
  • Billing.
  • SLA.
  • Dashboards B2B.
  • API enterprise.
  • Base licenciável.
  • Expansão de categorias/verticais.
  • Motor de recomendação avançado.

Time necessário

  • Head de Produto.
  • CTO.
  • 3 a 5 engenheiros.
  • 2 data/catalog engineers.
  • 4 a 8 catalog analysts.
  • 2 CS/onboarding.
  • 2 sales/parcerias.
  • Jurídico/compliance recorrente.
  • Marketing técnico/conteúdo.

Dependências

  • Product-market fit B2B.
  • Qualidade consistente.
  • Processos de suporte.
  • Contratos de dados/imagens.
  • Infra escalável.

Riscos

  • Crescer com dados ruins.
  • Suporte escalar mal.
  • Concorrentes copiarem interface.
  • Disputa de dados/licenças.
  • Custo de curadoria alto.

Critérios de sucesso

  • Receita recorrente B2B.
  • Base técnica difícil de copiar.
  • Fornecedores alimentando dados.
  • Lojas usando no dia a dia.
  • Redução de devolução comprovada.
  • Expansão sem perder qualidade.

KPIs

  • MRR/ARR.
  • Churn.
  • LTV/CAC.
  • API calls pagas.
  • Widget conversions.
  • SKUs curados.
  • Fitments aprovados.
  • % fitments com campo validado.
  • No-result rate.
  • Tempo de curadoria.
  • Margem por canal.

Backlog

  • Billing.
  • OpenSearch.
  • API enterprise.
  • Widget white-label.
  • Portal fornecedor premium.
  • Analytics avançado.
  • IA assistida.
  • Integrações ERP/e-commerce.
  • Marketplace controlado.
  • Licenciamento de dados.

Priorização

  • Receita recorrente.
  • Qualidade/defensabilidade.
  • Automação de dados.
  • Expansão vertical.
  • Marketplace somente se base estiver madura.

Não fazer

  • Expandir todas as verticais ao mesmo tempo.
  • Baixar padrão de validação.
  • Vender dados sem contrato robusto.
  • Abrir marketplace sem governança.

Planos transversais

Execução por frente

Plano de contratação

Contratar conforme risco de execução, começando enxuto e reforçando dados, produto e B2B.

  • 0-3 meses: CTO/fullstack senior, Product/Ops owner, 1 catalog analyst, UX part-time.
  • 3-6 meses: fullstack adicional, data/catalog analyst, customer success piloto, QA part-time.
  • 6-12 meses: backend/API engineer, data engineer, partnerships manager, 2 catalog analysts, suporte/onboarding.
  • 12-24 meses: Head de Produto ou PM senior, Sales B2B, CS manager, data platform engineer, security/compliance advisor, conteúdo técnico.

Plano de fornecedores

Criar relação de troca: diagnóstico de catálogo e demanda em troca de dados melhores.

  • Começar com 10 fornecedores off-road.
  • Oferecer diagnóstico gratuito de catálogo.
  • Criar score de qualidade por fornecedor.
  • Priorizar quem envia imagem, manual, OEM e aplicações.
  • Dar relatórios de demanda como incentivo.
  • Formalizar termos de uso/licença de dados e imagens.

Plano de dados

Manter qualidade como restrição de produto, não como tarefa posterior.

  • Dado sem fonte não publica como compatível.
  • Base inicial pequena e profunda.
  • Importação sempre entra com quarentena quando houver conflito.
  • Medir no-result e priorizar catálogo.
  • Criar rotina semanal de revisão.
  • Usar feedback de campo para subir/descer score.

Plano técnico

Construir primeiro o core transacional e só adicionar infraestrutura pesada quando houver necessidade real.

  • MVP com Next.js, Postgres, Prisma, Auth, RBAC e S3-compatible.
  • Busca em Postgres inicialmente.
  • Redis/OpenSearch/Neo4j depois, por necessidade.
  • Testes no core de fitment.
  • Auditoria desde o início.
  • Deploy staging e produção com backups.

Plano comercial

Vender redução de erro, ganho de velocidade e qualidade técnica antes de vender escala.

  • Fase 0-1: validação e relacionamento.
  • Fase 2: pilotos gratuitos ou pagos simbólicos.
  • Fase 3: planos beta para loja, fornecedor e widget.
  • Fase 4: SaaS/API/analytics/licenciamento.
  • Proposta de valor: menos erro, menos devolução, venda mais técnica.

Plano de conteúdo e imagens

Usar mídia como evidência e confiança, não só como vitrine.

  • Priorizar imagens úteis, não decorativas.
  • Toda imagem com fonte/licença.
  • Criar padrão de foto por categoria.
  • Manuais/fichas técnicas como evidência.
  • Conteúdo SEO por veículo/categoria após dados confiáveis.
  • Não copiar catálogo protegido sem autorização.

Validação com usuários reais

Observar o balcão e a oficina antes de escalar produto ou monetização.

  • Recrutar 5 oficinas e 5 lojas.
  • Observar uso no balcão/oficina.
  • Medir tempo até resposta.
  • Coletar buscas sem resultado.
  • Comparar devoluções antes/depois.
  • Rodar entrevistas quinzenais.
  • Criar canal rápido para reportar serviu/não serviu.
  • Transformar feedback em backlog semanal.
Ordem de maturidade obrigatória

O roadmap só cria vantagem competitiva se a plataforma avançar em sequência: dados confiáveis, uso real, fornecedores/API e só então escala comercial.