Ucopiloto: Conectando Motoristas e Oficinas
Aplicativo de Gestão Automotiva Inteligente
Aplicativo para conectar motoristas e oficinas de maneira inteligente, simplificando agendamentos, orçamentos e o acompanhamento de serviços automotivos, do zero ao lançamento comercial.
O Ucopiloto representa a construção, do zero ao lançamento comercial, de um app que conecta motoristas e oficinas, operado ponta a ponta por um único engenheiro, do produto à infraestrutura.
Visão Estratégica
O Ucopiloto nasceu para resolver um problema simples de enunciar e difícil de operar bem: encontrar uma oficina de confiança, agendar um serviço e acompanhar tudo sem depender de ligações e planilhas. A proposta da Click Software House era digitalizar essa jornada ponta a ponta.
O que precisava funcionar desde o dia 1
- Agendar serviços automotivos com poucos toques, do lado do motorista
- Gerenciar demanda, orçamentos e histórico de veículos, do lado da oficina
- Manter os três produtos (app, web e admin) sempre em sincronia
Contexto e Construção do Produto
Como único engenheiro no projeto, atuei em todas as frentes: modelagem de dados, APIs, aplicativo mobile, painel web, admin e infraestrutura. A estratégia foi tratar agendamento e orçamento como o núcleo transacional do sistema — a parte que não podia falhar — e só então expandir para funcionalidades de suporte, como histórico de veículos e notificações.
API
Regras de agendamento, orçamento e histórico de veículos.
Web + Admin (Next.js)
Gestão operacional das oficinas e visão consolidada do negócio.
Mobile (React Native)
Experiência do motorista, do agendamento ao acompanhamento.
Protótipo de baixa fidelidade da tela de agendamento
Arquitetura e Decisões Técnicas
Mesmo sem uma equipe de infraestrutura, o Ucopiloto precisava se comportar como um sistema de produção sério: múltiplos serviços, cada um isolado em seu próprio container, com contratos de API estáveis entre app, painel web e admin. A arquitetura foi desenhada para que qualquer parte do sistema pudesse falhar, reiniciar e voltar sozinha, sem intervenção manual.
Domínio isolado por módulo
NestJS organiza a API em módulos (agendamento, orçamento, veículos, notificações), cada um com suas próprias regras e testabilidade.
Dados consistentes e tipados
PostgreSQL com modelagem relacional para agendamentos e orçamentos, acessado via Prisma para reduzir erros de tipo em produção.
Containers auto-recuperáveis
Cada serviço roda em container próprio no Docker, com restart policy e healthcheck: uma falha não derruba o sistema inteiro.
Deploy sem downtime perceptível
Imagens versionadas e deploy automatizado permitem atualizar a API em produção sem interromper agendamentos em andamento.
Contrato único de API
App mobile, painel web e admin consomem a mesma API REST, eliminando divergência de regras de negócio entre plataformas.
Backups e jobs assíncronos
Rotinas de backup e tarefas de notificação rodam como jobs separados da API, sem competir por recursos com requisições em tempo real.
Toda a stack foi escolhida para que um único engenheiro conseguisse manter API, banco, jobs e observabilidade em produção — todos containerizados e isolados entre si — com 99,9% de uptime, mesmo sem uma equipe de infraestrutura dedicada.
Execução e Integração
A execução cobriu o fluxo completo: cadastro de motoristas e oficinas, agendamento, orçamento, acompanhamento do serviço e histórico. O app mobile, o painel web e o admin conversavam sempre com a mesma API.
Princípios de implementação
- Um único contrato de API para app, web e admin
- Validações de agendamento centralizadas no backend
- Componentização para reduzir retrabalho entre telas
- Monitoramento básico desde o primeiro deploy
Painel do motorista: lucro, faturamento e km do dia
Gestão do veículo: abastecimento, manutenção e despesas
Busca de oficinas próximas em tempo real
Deploy e Operação
Como responsável único por DevOps, containerizei toda a aplicação com Docker: API, banco de dados, jobs assíncronos e reverse proxy rodam como serviços independentes, cada um com sua própria política de restart e healthcheck. Isso garante ambientes reprodutíveis e simplifica deploys e rollbacks, sem depender de acesso manual ao servidor em cada atualização.
A operação solo exigiu disciplina em:
- Automação de deploy para reduzir erro humano e permitir rollback em minutos
- Healthcheck e restart automático por container, isolando falhas por serviço
- Observabilidade mínima viável desde o início: logs estruturados e alertas básicos
- Rotinas de backup do PostgreSQL testadas e agendadas como jobs próprios
- Documentação enxuta para acelerar decisões futuras sem depender de memória
Esse cuidado se traduziu em 99,9% de uptime mesmo sem uma equipe de infraestrutura dedicada — a robustez do sistema vem da isolação entre serviços e da automação, não do tamanho do time.
Segurança, Observabilidade e Decisões Técnicas
Mesmo mantido por um único engenheiro, o Ucopiloto foi construído com as práticas de segurança e observabilidade que se espera de um sistema de produção — para falhar com segurança e se recuperar sozinho.
Segurança
- Autenticação por token (JWT) e contratos de API tipados (TypeScript), eliminando classes inteiras de bug
- Rate limiting e validação de entrada na borda da API
- Segredos por ambiente e TLS; cada serviço isolado em seu container
Observabilidade
- Healthcheck + restart policy por container: auto-recuperação sem intervenção manual
- Logs estruturados e monitoramento de uptime (99,9%)
- Jobs assíncronos (backup, notificação) separados da API, sem competir por recursos em tempo real
Decisões & trade-offs
- Monólito modular em NestJS em vez de microsserviços: um engenheiro mantém tudo, com domínio isolado por módulo
- Prisma para eliminar erros de tipo em produção, abrindo mão de SQL manual mais performático porém arriscado
- Deploy versionado sem downtime perceptível, em vez da simplicidade de um deploy manual
Impacto do Projeto
O Ucopiloto consolidou uma base confiável para conectar motoristas e oficinas, com mais de 200 usuários ativos, 99,9% de uptime e uma redução de 35% no tempo de agendamento em relação ao processo manual anterior.
Além do resultado técnico, o projeto validou que um único engenheiro, com as escolhas certas de arquitetura, pode sustentar um produto multiplataforma em produção com qualidade e estabilidade.
Trade-offs e o que eu faria diferente
O que optei por não fazer
- Kubernetes: com DevOps solo e um único ambiente de produção, Docker Compose com deploy simples entregava a mesma confiabilidade com muito menos superfície pra operar sozinho.
- Dashboard de analytics próprio: usei Grafana sobre as métricas já coletadas em vez de construir uma tela de admin dedicada, pra manter o escopo fechado nos 5 meses até o lançamento.
O que eu faria diferente hoje
Introduziria testes E2E automatizados antes do primeiro release em produção, não depois. O prazo de 5 meses e a operação solo empurraram a cobertura de testes pra depois do lançamento, o que funcionou, mas deixou a primeira fase mais dependente de smoke tests manuais do que eu gostaria.
Principais Desafios Enfrentados
Conectar os dois lados de um mercado fragmentado, motoristas e oficinas, exigia mais do que telas bonitas: exigia confiabilidade operacional desde o primeiro agendamento.
Sincronizar agendamentos e orçamentos em tempo real entre app, painel web e admin
Garantir uptime alto operando como DevOps solo, sem equipe de infraestrutura dedicada
Reduzir o tempo de agendamento sem sacrificar a integridade dos dados de veículos e serviços
Indicadores Técnicos Estruturais
- 200+ usuários ativos em produção
- 99,9% de uptime
- -35% no tempo de agendamento
- Infraestrutura containerizada com Docker
- Operação solo de DevOps ponta a ponta