TL;DR: Small fuel depots run on three disconnected tools: a stock spreadsheet, a pricing sheet and a paper or WhatsApp fleet log. Prices get set without current stock in view, and fleet losses surface only after a manual check. Depotline puts stock, price, margin and fleet consumption on one screen.

Built product · Product owner · Live demo (sample data)

Live demo · PRD · BRD · MRD · Spec · Code

The problem

The one- or two-person depot has no ERP budget and no ops team, and the core failure is simple: pricing decided without knowing current stock cost. Fleet fuel is logged on paper or WhatsApp, so a vehicle drawing too much only shows up when someone sits down and checks by hand.

Evidence

This came from running fuel operations in India and Southern Africa, where I saw depots work exactly this way. Related case study: FuelTracker: Loss-Control SaaS for Industrial Sites (Fuel), the enterprise version of the same loss-control problem. Depotline itself has only been run on sample data.

How it works

flowchart LR
	A["Stock received<br>volume + cost"] --> B["Stock level<br>per fuel type"]
	B --> C["Set price against<br>last-in stock cost"]
	C --> D["Live margin<br>per fuel type"]
	E["Fleet fuel entry<br>per vehicle"] --> F["Compare to<br>fleet average"]
	F --> G["Flag outlier vehicle"]
	D --> H["One dashboard"]
	G --> H
	B --> H

Decisions and trade-offs

  1. One screen instead of three tools. Stock, pricing and fleet logs share a dashboard.
  2. Margin as a live number. Price per fuel type is set against last-in stock cost, so margin is always visible.
  3. Running log before trend analytics. Each vehicle's latest volume is compared to the fleet average; per-vehicle history is parked for v1.1 until the target operator shows they need it.
  4. No POS/ERP integration or invoicing. Integrations add setup cost before the core loop is proven.
  5. Responsive web, not a native app. Operators already have a phone and a browser.

What I cut