Tiye Super App - Taxi, Jobs e Marketplace em Flutter

Resumo

• Entrega: módulos end-to-end de Taxi (ride-hailing), Jobs (board + wizard de candidatura) e evolução pesada de Marketplace (listagens, ferramentas de seller e fluxos de negociação).
• Como eu destravei: padronizei o fluxo UI → Notifier → Service → Model, com parsing defensivo e blocos reutilizáveis para manter velocidade sem quebrar telas.
• Efeito prático: o app ganhou features reais de produto (não só telas), com integrações de maior risco (mapa/localização/upload) e base mais modular por domínio.

Em ~4 meses, fui responsável por entregar e estabilizar features críticas em um super-app Flutter, integrando APIs REST e módulos de alto acoplamento (mapa, estado da corrida, upload de arquivos) sob restrições de pouca infra de qualidade (testes/CI) e pressão por evolução rápida.

Contexto

• Produto e usuários: super-app multi-domínio (serviços + marketplace), com experiências para usuário final e áreas específicas por papel (ex.: seller/driver).
• Por que era crítico: Taxi e Marketplace são “core loops” de retenção e monetização - sem eles, o app vira vitrine.
• Restrições reais: baixa cobertura de testes e pouca automação de entrega; mudanças precisavam ser incrementais e seguras.

Principais desafios

• Estado e fluxo complexos (Taxi): múltiplos modos (driver/passageiro), sincronização de mapa, permissões e ciclo da corrida.
• Escalar sem virar “spaghetti”: várias frentes no mesmo app, com pressão por velocidade e retrabalho caro.
• Payloads inconsistentes de API: domínios grandes (Marketplace/Property) exigindo parsing robusto e tolerante a nulls/formatos.

O que eu fiz

• Taxi & Ride-hailing: implementei o fluxo completo (telas + estado + integrações) com Google Maps e Geolocator, incluindo organização de Notifiers/Services e componentes reutilizáveis de mapa.
• Jobs (board + apply): criei listagem, detalhes e um fluxo multi-etapas de candidatura (incluindo upload), estruturado para reuso e evolução.
• Marketplace + Search + Seller tools: evoluí listagens com paginação/infinite scroll, melhorei busca e fortaleci Services/Models para suportar seller dashboards e fluxos de negociação.
• Auth & Roles: reforcei autenticação com armazenamento seguro e acesso baseado em papéis (User/Seller/Driver), reduzindo fricção de sessão/token no app.
• Media/News: integrei uma área de mídia/notícias com consumo de conteúdo via YouTube.

Decisões & trade-offs

• Provider/ChangeNotifier como padrão ativo de estado: mantive a lógica de domínio fora das telas por meio de Notifiers e injeção via Providers.
  Trade-off: sem uma arquitetura/testes bem estabelecidos, exige disciplina para não virar lógica espalhada.
• Parsing defensivo nos models (especialmente Marketplace/Property): priorizei tolerância a payloads instáveis (nulls/fields faltando).
  Trade-off: mais código “chato” em mappers/models, mas menos crash e menos hotfix urgente.
• Integrações primeiro, polimento depois: Maps/Location/Upload são multiplicadores de risco; atacar isso cedo evitou rework.
  Trade-off: parte do refinamento visual/UX fica para ciclos seguintes quando o fluxo real já está de pé.

Resultados

• Medido (engenharia): 20 commits verificados no recorte extraído (Fev–Jun/2025), com entregas maiores por commit.
• Proxy técnico (concreto):
  • Ciclo de corrida do Taxi com integração de Maps/Geolocalização e fluxos dependentes de papel (driver/passageiro).
  • Módulo de Jobs com listagem/detalhe e fluxo multi-etapas de candidatura (incl. upload).
  • Evolução do Marketplace com paginação, melhorias de busca e ferramentas/fluxos orientados a seller.
  • Autenticação por papel com armazenamento seguro, além de integração de Media/News com YouTube.
• Operacional: separação mais clara por domínio/feature (estado + services + models), facilitando tocar múltiplas frentes sem travar o app.

Nota: métricas sensíveis de produto (usuários/GMV/volume de corridas) não estavam acessíveis; evidências técnicas podem ser compartilhadas em um “proof pack” redigido sob solicitação.

O que eu faria diferente

• Adicionar testes de verdade (unit + widget/integration) e definir um mínimo não negociável por feature (notifier + service + parsing).
• Implementar CI/CD (build + lint + testes + checks) para reduzir regressões e acelerar entregas.
• Remover dependências não utilizadas ou planejar migração com estratégia clara (ex.: manter o padrão atual ou migrar estado de forma incremental e testada).