QWIP

O contexto

Dono de posto vive entre planilhas e relatórios de papel: venda diária por combustível, inventário financeiro, evolução de patrimônio, custo versus venda. O QWIP condensa isso em indicadores claros no celular. Cada cliente (grupo de postos) é um tenant com banco de dados isolado — o mesmo produto atende todos, separados com segurança.

Decisões que foram minhas

1. 01Multi-tenant por subdomínio, isolado por banco

   Cada cliente ganha um subdomínio, e o backend resolve isso para uma conexão PostgreSQL dedicada. Dados financeiros de grupos diferentes nunca dividem banco — uma decisão de arquitetura que torna auditoria e onboarding triviais de explicar.

2. 02Um vocabulário TypeScript em três apps

   Next.js na web, Expo no mobile, NestJS + TypeORM no backend. Sendo o único engenheiro, otimizei para andar rápido sem quebrar contratos: os mesmos tipos descrevem um relatório do banco até a tela.

3. 03SwiftUI nativo onde o app iOS pede

   O app iOS é Expo, mas parte dele é escrita nativamente em SwiftUI — as telas em que o toque nativo e a renderização certinha da plataforma importam mais que reaproveitar entre plataformas. Vou para a camada nativa de propósito, não por padrão, e faço a ponte de volta para o app Expo.

4. 04Desenhado para números serem lidos, não decifrados

   O produto é majoritariamente tabela e indicador — então o design foi para a hierarquia: litros, tickets e médias alinhados e escaneáveis, relatórios exportáveis em PDF que o dono arquiva ou encaminha. UI sóbria, zero ruído.

5. 05Publicado como produto, não como projeto de gaveta

   Ficha na App Store na minha própria conta de desenvolvedor, screenshots de loja desenhados por mim, clientes reais em produção. Ser dono do ciclo inteiro — código, design, infra, publicação — é o ponto deste projeto.

Onde isso chegou

No ar na App Store e na web, atendendo grupos de postos reais em produção com relatórios e indicadores financeiros diários.