Nota para revisão: não há link público de demonstração para este projeto (sistema interno de gestão de frota de um cliente). O texto abaixo descreve a arquitetura técnica real, sem métricas de negócio (número de veículos, motoristas ativos, redução de custo) — se houver dados que possam ser divulgados com autorização do cliente, me avisa que eu incluo em Resultados.
Problema
Empresas de transporte com frota própria (motoristas, veículos, manutenção, ordens de serviço) costumam gerenciar isso em planilhas ou sistemas fragmentados: um controle para motoristas, outro para veículos, checklist em papel, manutenção acompanhada de forma reativa. Isso gera dois problemas recorrentes — falta de visibilidade centralizada da operação (quem está dirigindo o quê, qual veículo precisa de manutenção) e checklist de veículo que depende de disciplina manual, sem registro confiável de quando e como foi feito.
Também há o problema de manter dois produtos (painel administrativo web e aplicativo do motorista para celular) sincronizados e consistentes, o que normalmente significa duas bases de código separadas evoluindo em paralelo, com risco de divergência entre elas.
Solução
Desenvolvi um sistema de gestão de frota que cobre demandas, motoristas, veículos, empresas clientes, estoque de peças, manutenção preventiva com alertas e ordens de serviço, com dois pontos de acesso: um painel administrativo web e um aplicativo do motorista para Android e iOS.
A decisão central do projeto foi gerar o painel web e o aplicativo mobile a partir da mesma base de código Next.js, usando Capacitor para empacotar a aplicação web como app nativo Android/iOS. Isso elimina a duplicação de lógica entre uma versão web e uma versão mobile nativa separada — a interface e as regras de negócio no frontend são escritas uma vez e rodam nos dois contextos.
O aplicativo do motorista cobre checklists de veículo direto no celular (substituindo o registro em papel por um fluxo digital com histórico) e notificações, enquanto o painel administrativo web concentra a gestão de demandas, frota, estoque de peças e ordens de serviço.
Arquitetura
O frontend é construído em Next.js 15 com TypeScript, usando Radix UI e shadcn/ui como base de componentes — uma escolha que prioriza componentes acessíveis e não estilizados (Radix) combinados com um sistema de design consistente por cima (shadcn/ui), em vez de uma biblioteca de UI fechada.
Capacitor 7 é a camada que transforma essa mesma aplicação web em app nativo para Android e iOS, dando acesso a APIs nativas do dispositivo (câmera para fotos de checklist, notificações push) sem precisar manter uma base de código React Native ou nativa separada.
O backend é uma API REST em PHP com autenticação via JWT, responsável por persistir e servir os dados de demandas, motoristas, veículos, empresas clientes, estoque de peças e ordens de serviço, além de disparar os alertas de manutenção preventiva com base em critérios como quilometragem ou tempo desde a última manutenção.
A separação entre frontend (Next.js/Capacitor) e backend (API PHP/JWT) segue o modelo desacoplado: o mesmo backend serve tanto o painel web quanto o app mobile, garantindo que motorista e administrador vejam sempre o mesmo estado da operação, sem dados divergentes entre as duas superfícies.
Módulos como manutenção preventiva com alertas e checklist de veículo no mobile respondem diretamente ao problema de visibilidade: em vez de descobrir que um veículo precisa de manutenção quando ele já apresenta problema, o sistema monitora e alerta antes, e o checklist digital cria um histórico consultável em vez de papéis perdidos.
Decisões de design
A escolha de Capacitor sobre uma stack mobile nativa separada (React Native, ou nativo Android/iOS de fato) foi guiada pelo escopo do produto: o aplicativo do motorista não depende de recursos nativos exóticos além de câmera e notificação, então o custo de manter duas bases de código (uma web, uma mobile) não se justificava frente ao ganho de reaproveitar toda a lógica de negócio, componentes de interface e integrações com a API já construídos para o painel web.
Radix UI e shadcn/ui, combinados, resolvem um problema comum em projetos que têm painel administrativo denso (muitas telas, tabelas, formulários): dão acessibilidade e comportamento correto de componentes complexos (modais, selects, tooltips) sem amarrar o projeto a um design system fechado que depois precisa ser sobrescrito para caber na identidade visual do produto.
A autenticação via JWT na API PHP permite que tanto o painel web quanto o app mobile do motorista se autentiquem contra o mesmo backend com o mesmo mecanismo, sem precisar de sessões stateful no servidor — importante para o app mobile, que pode ficar offline e precisa gerenciar token localmente entre sessões de uso.
Stack
Next.js 15, TypeScript, Radix UI e shadcn/ui (frontend do painel e do app mobile), Capacitor 7 (empacotamento nativo Android/iOS), PHP (API REST backend), MySQL (persistência), JWT (autenticação da API).