QWIP

The context

Gas station owners live between spreadsheets and paper reports: daily fuel sales, financial inventory, asset evolution, cost versus price. QWIP condenses that into clear indicators on a phone. Each client (station group) is a tenant with its own isolated database — the same product serves them all, securely separated.

Decisions that were mine

1. 01Multi-tenant by subdomain, isolated by database

   Each client gets a subdomain, and the backend resolves it to a dedicated PostgreSQL connection. Financial data from different station groups never shares a database — an architecture decision that makes audits and onboarding trivially explainable.

2. 02One TypeScript vocabulary across three apps

   Next.js on the web, Expo on mobile, NestJS + TypeORM on the backend. Being the only engineer, I optimized for moving fast without breaking contracts: the same types describe a report from the database to the screen.

3. 03Native SwiftUI where the iOS app earns it

   The iOS app is Expo, but part of it is written natively in SwiftUI — the screens where a native feel and platform-perfect rendering matter more than cross-platform reuse. I reach for the native layer deliberately, not by default, and bridge it back into the Expo app.

4. 04Designed for numbers to be read, not decoded

   The product is mostly tables and indicators — so the design work went into hierarchy: liters, tickets and averages aligned and scannable, reports exportable as PDFs the owner can file or forward. Sober UI, zero noise.

5. 05Shipped like a product, not a side project

   App Store listing under my own developer account, store screenshots designed by me, real clients in production. Owning the whole loop — code, design, infra, publishing — is the point of this project.

Where it landed

Live on the App Store and on the web, serving real gas station groups in production with daily financial reports and indicators.