Destinatário
Futuro cliente, equipe técnica avaliadora, gestores de operação e responsáveis pela decisão de compra do código-fonte.
Relatório técnico completo da plataforma I9VANDO para aquisição de código-fonte.
Documento técnico para equipe de tecnologia, suporte, operação e decisão de compra. O conteúdo descreve arquitetura, módulos, integrações, operação, entregáveis, governança e critérios recomendados para aquisição do ecossistema white label.
Finalidade
Avaliar tecnicamente a aquisição do código-fonte da plataforma white label, entendendo módulos, responsabilidades, riscos, integrações e continuidade operacional.
Escopo
Descrição da arquitetura, aplicativos, backends, painéis, integrações, operação, entregáveis, governança, segurança, implantação e critérios de aceite.
Referência de validação
Fluxos e demonstrações já existentes no site i9vando.com.br. Não há previsão de testes adicionais além dos fluxos demonstráveis já disponibilizados publicamente.
Sumário executivo
Plataforma completa, não apenas um aplicativo
A I9VANDO é um ecossistema white label de mobilidade urbana voltado para empresas que desejam operar aplicativos próprios de transporte de passageiros, entregas, mototáxi, táxi/transporte executivo, reboque e serviços personalizados.
A solução combina aplicativos móveis, painéis administrativos, central SaaS, comunicação em tempo real, rádio PTT, treinamento, integrações de pagamento e recursos de automação operacional. O valor técnico está na integração entre todos esses componentes.
| Pergunta técnica | Resposta objetiva |
|---|---|
| O produto é apenas um aplicativo? | Não. A plataforma é composta por apps, backends, central SaaS, rádio em tempo real, treinamento, painéis, integrações e documentação de API. |
| O sistema é white label? | Sim. Cada operação pode usar sua marca, domínio, identidade visual, configurações, módulos e regras comerciais. |
| A compra do fonte exige transferência técnica? | Sim. A aquisição deve envolver repositórios, documentação, scripts, guias de deploy, configuração das contas externas e acompanhamento técnico. |
| Qual é o cuidado principal? | Separar claramente código, dados, marca, contas externas, segredos, ambientes existentes e suporte pós-entrega. |
Conclusão executiva
A plataforma está estruturada como produto operacional completo. Para venda de código-fonte, o formato recomendado é transferência assistida com ambiente de homologação, documentação técnica, checklist de aceite, contrato de confidencialidade e matriz clara de responsabilidades.
1. Visão geral da plataforma
Operação white label de mobilidade
Aplicativos, painéis, pagamentos, rádio, treinamento e automação organizados para empresas que desejam operar com marca própria.
P
Aplicativo Passageiro
Solicitação de viagens e entregas, localização, mapa, categorias, pagamentos, agendamento, histórico, recibo e acompanhamento em tempo real.
M
Aplicativo Motorista
Disponibilidade online, aceite de corridas, navegação, ganhos, rádio PTT, suporte remoto, notificações e treinamento.
A
Painel Master
Administração de motoristas, passageiros, frota, tarifas, zonas, módulos, relatórios, importações e operação diária.
S
Central SaaS
Gestão dos clientes white label, planos, módulos, integrações externas, links, suporte e governança administrativa.
D
Despachante Web
Criação e acompanhamento de solicitações pela equipe operacional, com domínio do cliente e fluxo externo ao painel principal.
T
Treinamento
Portal de capacitação com aulas, progresso, exames e certificados para reduzir dúvidas e melhorar a operação.
A solução foi desenhada para permitir que cada operação tenha identidade própria e configure recursos de acordo com sua necessidade comercial. A Central SaaS mantém a governança dos clientes, enquanto o Master executa a operação diária da marca white label.
2. Arquitetura técnica macro
Separação por responsabilidade
A arquitetura utiliza camadas especializadas. Os aplicativos Flutter concentram a experiência móvel. O Master centraliza a operação do cliente. A Central administra a camada SaaS. O servidor de Rádio PTT mantém a comunicação em tempo real. O Treinamento funciona como camada educacional e certificação.
| Componente | Responsabilidade | Tecnologias principais |
|---|---|---|
| Apps Flutter | Experiência passageiro e motorista para Android, iOS e Web/PWA quando aplicável. | Flutter, Dart, Firebase, Google Maps, Dio, Bloc, Drift, WebRTC e Socket.IO. |
| Master | Painel administrativo operacional de cada cliente white label. | Laravel 10, PHP 8.2+, Tailwind/Vite e MySQL. |
| Central | Gestão SaaS dos clientes, planos, módulos, links, integrações e suporte. | Laravel 12, PHP 8.2+, Tailwind/Vite e MySQL. |
| Rádio PTT | Canais globais e por viagem, presença, áudio em tempo real e gravações. | Node.js, Express, Socket.IO, WebRTC e Multer. |
| Treinamento | Aulas, progresso, exames, certificados e painel administrativo. | Laravel 12, PHP 8.2+ e geração de PDF. |
3. Estrutura de código-fonte recomendada
Pacotes por domínio funcional
Para aquisição de código-fonte, o comprador deve receber os repositórios por domínio funcional. Essa organização facilita manutenção, auditoria, customização, implantação e governança.
| Pacote recebido | Conteúdo técnico esperado |
|---|---|
| Backend Master | Controllers, models, requests, policies, services, jobs, views, assets front-end, migrations, seeders, APIs e rotas administrativas. |
| Central SaaS | Gestão dos clientes, módulos, planos, integrações, documentação pública de API, permissões e automações administrativas. |
| Serviço Rádio PTT | Código Node.js, canais de socket, autenticação, presença, WebRTC, Socket.IO, persistência e painel de monitoramento. |
| Portal de Treinamento | Cursos, aulas, progresso, exames, certificados, painel administrativo e assets do tema. |
| Apps Flutter | Passageiro e motorista com configuração por cliente, Firebase, mapas, permissões, build Android/iOS e documentação de publicação. |
| Documentação e implantação | Variáveis, comandos, configuração de servidor, webhooks, contas, backups, monitoramento e checklist. |
Controle de segredos
A entrega de código-fonte deve ocorrer com arquivos de exemplo sem segredos reais expostos. Chaves de produção, tokens, contas de terceiros, dados reais de clientes, senhas e certificados devem ser transferidos apenas por canal seguro validado.
4. Stack e dependências técnicas
Base tecnológica
A plataforma utiliza múltiplas tecnologias porque cada camada possui uma responsabilidade operacional específica. A aquisição deve considerar versões, dependências, contas externas e compatibilidade entre aplicativos, backends e provedores.
| Camada | Stack atual ou esperada | Observações |
|---|---|---|
| Backend | Laravel 10+ e Laravel 12 | Master, Central e Treinamento têm responsabilidades separadas. |
| Front-end web | Vite, Vue/Blade, Tailwind/Bootstrap | Painéis administrativos, central, ambiente e telas comerciais. |
| Mobile | Flutter e Dart | Apps Android, iOS e Flutter Web quando aplicável. |
| Banco de dados | MySQL/MariaDB multi-cliente | Viagens, passageiros, motoristas, tarifas, módulos, relatórios e carteiras. |
| Tempo real | Firebase, FCM, Socket.IO e WebRTC | Localização, presença online, notificações, chamadas, rádio e comunicação operacional. |
| Mapas | Google Maps, Places, Directions/Routes API e geocoding | Autocomplete, distância, rota, zonas, acompanhamento ao vivo e cálculo operacional. |
| Pagamentos | Mercado Pago/i9Pay, PIX, cartão, split/application_fee e carteira digital | PIX, cartão, application_fee, carteira digital, recibos, histórico e conciliação. |
| Integrações auxiliares | Webhooks, SMTP por cliente, Evolution API e documentação OpenAPI | Integração com CRM, WhatsApp, e-mails transacionais e sistemas externos. |
A presença de múltiplas tecnologias não representa fragmentação quando há separação clara de responsabilidades. O ponto crítico para aquisição é manter documentação de versão, matriz de ambientes e rotina de atualização para SDKs móveis, Firebase, Google Maps, pagamentos e bibliotecas.
5. Módulos funcionais do produto
Solicitação de viagem
Origem, destino, categorias, preferências, cupom, pagamento, distância, tempo, agendamento, cobrança adicional por passageiro e validações operacionais.
Operação do motorista
Disponibilidade online, aceite de corrida, chegada, início, finalização, ganhos, carteira digital, avaliação, rádio PTT e suporte remoto.
Gestão administrativa
Motoristas, passageiros, frota, permissões, tarifas, zonas, importações, relatórios, módulos por cliente e operação diária.
Mapas e zonas
Olho de Deus, geofencing, Zona VIP, área de atuação, raio de busca, acompanhamento em tempo real e validação por zona.
Pagamentos e carteira
PIX/cartão i9Pay, pagar ao motorista, carteira digital, recibo, histórico, controle financeiro e conciliação por viagem.
Comunicação
Rádio PTT global e por viagem, notificações, atendimento operacional, suporte e recursos de comunicação em tempo real.
Passageiro Web/PWA
Solicitação pelo navegador em computadores, link por cliente e experiência baseada no mesmo ecossistema dos aplicativos.
Integrações externas
API pública, OpenAPI, webhooks para CRM, WhatsApp/Evolution API e configuração por cliente.
Os módulos são habilitados conforme operação e plano do cliente. Essa abordagem permite operar com recursos mínimos ou avançados sem exigir que uma ativação estrutural se aplique a todos os clientes ao mesmo tempo.
6. Integrações externas críticas
| Integração | Papel na operação | Ponto de atenção |
|---|---|---|
| Firebase | Autenticação, Firebase Database, FCM, localização, presença e notificações. | Projetos, regras, apps Android/iOS, APNs, FCM tokens e consistência entre status online. |
| Google Maps | Mapas, rotas, autocomplete, geocoding, distância e cálculo operacional. | Conta Google Cloud, APIs, custos, faturamento, chaves e restrição por domínio/app. |
| Mercado Pago/i9Pay | PIX/cartão, application_fee, carteira virtual e webhooks. | Módulo financeiro auditável, dependências, contas conectadas e responsabilidade de repasse. |
| Evolution API/WhatsApp | Instâncias, atendimento e solicitação de viagem por WhatsApp. | Ativação por cliente, webhook, instância dedicada e controle de fluxo. |
| SMTP por cliente | Envio de e-mails com domínio e identidade de cada operação. | Configuração por banco/cliente, fallback, logs e teste de conexão. |
| OpenAPI/Webhooks | Integração pública com CRMs e sistemas externos. | Catálogo de eventos, autenticação, logs, retries e versionamento de API. |
O uso transparente de integrações exige contratos próprios com provedores, credenciais, custos, limites de uso, ambiente de homologação e suporte técnico para operação contínua.
7. Segurança, LGPD e governança
Dados sensíveis e proteção operacional
A plataforma manipula dados sensíveis, incluindo localização, telefone, documentos, histórico de viagem, pagamentos, contas digitais e dados operacionais. A aquisição do código-fonte exige governança forte para evitar exposição de dados, credenciais e ambientes reais.
Separação por cliente
Domínio, tenant, permissões e regras por operação para evitar vazamento entre clientes white label.
Controle de acesso
Política por perfil: super admin, administrador do cliente, despachante, motorista e passageiro.
Proteção de credenciais
Tokens, Firebase, Google Maps, webhooks, SMTP, certificados e pagamento precisam de inventário seguro.
Auditoria e logs
Registro de viagens, pagamentos, módulos, importações, exclusão de dados e alterações críticas.
Privacidade
Política de privacidade por cliente, termos de uso, exclusão de usuários e retenção segura.
Contingência
Backups, restauração, quarentena de exclusão, monitoramento e plano de continuidade.
| Governança recomendada | Objetivo |
|---|---|
| Contrato de transferência | Definir regras de uso do código, ambiente, suporte e propriedade. |
| Matriz de acesso | Definir quem pode acessar repositórios, servidores, banco, Firebase, mapas e gateways. |
| Inventário de segredos | Listar credenciais que devem ser substituídas, transferidas ou revogadas. |
| Registro de aceite | Controlar versão dos módulos, apps, APIs, banco e assets entregues. |
8. Operação, escala e continuidade
Mobilidade exige tempo real
A operação de mobilidade depende de resposta rápida e sincronização entre localização, status online, notificações, raio de busca, cálculo de rota, pagamento, rádio e banco de dados.
| Evento crítico | Risco operacional | Como controlar |
|---|---|---|
| Chamada de viagem | Motorista online não receber chamada por atraso de sincronização, divergência entre app/Firebase/MySQL ou regra de busca. | Monitorar estado do motorista, token FCM, status em múltiplas fontes e raio de busca. |
| Mapa e rota | Erro de zona, cache, key ou resposta de API pode gerar cálculo incorreto de preço. | Validar Google Maps, fallback, cache, zona e configuração por cliente. |
| Rádio PTT | Áudio unidirecional ou travado quando muda status operacional. | Controlar canal, reconexão, liberação de microfone e teste de transição. |
| Pagamentos | Webhooks falham e livro financeiro não atualiza. | Idempotência, fila de processamento, conciliação e logs financeiros. |
| Multi-cliente | Ajuste global afetar cliente ativo. | Feature flags, backups por cliente, testes de impacto e rollback. |
A continuidade exige processo disciplinado: backup antes de mudança, rollout, logs, mapa de código, teste em cliente piloto, validação de fluxo, app preservado e cliente informado quando necessário.
9. Entregáveis para compra do código-fonte
Entrega técnica auditável
O pacote de aquisição deve ser entregue como produto técnico auditável. Entrega parcial ou desorganizada eleva risco de operação, atraso de customização, falhas em publicação de apps e dependência do vendedor.
Repositórios Git
Master, Central, Rádio PTT, apps Flutter, site e documentação aplicável.
Instalação e banco
Scripts, migrations, seeders, criação de cliente/tenant e guia de banco de dados com dados não sensíveis.
Build mobile
Manual de build Android/iOS, lojas, Firebase, Maps, permissões, cores, imagens e personalização.
Deploy e infraestrutura
Linux, PHP-FPM, Nginx, Node.js, supervisores, cron, certificados, publicação e rotinas operacionais.
API e integrações
Documentação de API, OpenAPI JSON, webhooks, payloads e exemplos de integração.
Governança
Lista de dependências, licenças, contas externas necessárias, matriz de responsabilidades, evidências e suporte pós-transferência.
Exclusões que precisam estar claras
A negociação deve deixar explícito se inclui ou não banco de dados ativo dos clientes atuais, contas Google/Apple, Mercado Pago, Google Cloud, Firebase, domínios, servidores, certificados, números de WhatsApp, servidores existentes e suporte contínuo.
10. Due diligence técnica e comercial
| Tema | Validação recomendada | Evidência recomendada |
|---|---|---|
| Propriedade intelectual | Dono do código, licença, uso de pacotes, direito de revenda e sublicença. | Contrato, declaração de titularidade e inventário de dependências. |
| Código e versão | Compatibilidade entre apps, backend, banco, Firebase, Maps e pagamentos. | Releases de versão, changelog e checklist de build. |
| Banco de dados | Estrutura multi-cliente, migrações, seeders e dados de treinamento. | Dump sanitizado, migrations e mapa de relacionamento. |
| Infraestrutura | Domínios, servidores, cron, supervisor e logs existentes. | Runbook de servidor, recursos mínimos e rotina de backup. |
| Pagamentos | Mercado Pago/i9Pay, taxas, carteira, recibos e conciliação. | Fluxo de checkout, demonstração e amostra de recibo. |
| Publicação | Build Android/iOS, bundle IDs, permissões, purpose strings, privacy manifest e políticas de loja. | Guia de publicação e lista de permissões justificadas. |
| Suporte | Operação pós-entrega e evolução futura. | SLA, horas técnicas, escopo de garantia e canais de atendimento. |
Aquisição do código
Definir módulos, repositórios, licenças, responsabilidades e limites da entrega.
Implantação técnica
Subir ambiente, banco, serviços, apps e integrações em operação validada.
Transferência de conhecimento
Treinar equipe técnica sobre arquitetura, deploy, suporte e manutenção.
Suporte pós-entrega
Período assistido para estabilização, dúvidas técnicas e correções acordadas.
11. Próximos passos para avaliação
Revisar NDA
Formalizar confidencialidade antes de qualquer acesso a repositórios, banco, infraestrutura ou documentação interna detalhada.
Definir escopo exato
Confirmar quais sistemas, apps, módulos, ambientes e integrações serão incluídos na aquisição.
Validar demonstrações
Analisar os fluxos já disponíveis no site i9vando.com.br e no ambiente demonstrativo informado comercialmente.
Listar módulos e versões
Entregar matriz de módulos incluídos, versões previstas, dependências e responsabilidades técnicas.
Formalizar aceite
Definir checklist legal, financeiro, transição, fornecedor, pagamentos, lojas, rádio, webhooks e suporte.
Assinar contrato
Incluir propriedade, garantia, suporte de urgência, evolução contínua e obrigações de cada parte.
Conclusão técnica
A I9VANDO deve ser analisada como plataforma completa de mobilidade white label, não como um aplicativo isolado. O valor técnico está na integração entre apps, painéis, backend, tempo real, mapas, pagamentos, rádio, treinamento, webhooks e gestão SaaS. Para aquisição segura, a entrega precisa ser técnica, documentada e acompanhada. Uma transferência estruturada reduz risco operacional, protege dados, preserva qualidade e aumenta a chance de continuidade comercial após a compra.