Overview
Fuelnetra is a fuel-station management SaaS I built and shipped end to end — and it runs a real station, not a demo. It replaces the paper ledger every small fuel station still reconciles by hand: it reads the pump controllers directly, auto-matches online payments, tags credit sales, and reconciles the cash position in real time.
The one-line pitch on the landing page says it best: “Know where every litre and every rupee went — before your morning chai.”
The problem
A fuel station is a surprisingly hard cash-accountability problem wearing a simple costume. Fuel flows out of pumps; money comes back as a messy mix of cash, UPI/online payments, and credit (“put it on my account”). At day’s end an owner has to answer one question — does the fuel dispensed match the money collected? — and the honest answer usually lives across a paper notebook, a bank statement, and a worker’s memory.
Manual reconciliation is slow, error-prone, and quietly leaks money: meter tampering and fuel shrinkage don’t show up in a notebook. I wanted the numbers to reconcile themselves, and to surface the discrepancies a human eye would miss.
What it does
- Reads the hardware. Automated dispense data comes straight from the integrated fuel-pump controllers — no manual meter entry, which is where errors and fraud start.
- Per-worker shift reconciliation. Each worker’s shift closes against what their pumps dispensed vs. what they handed over — cash, online, and credit accounted for separately.
- A creditor book with aging. Credit sales are tracked per customer, with aging, so “who owes what, and for how long” is always current.
- A double-entry ledger. Handovers, deposits, and expenses all post to a proper double-entry ledger, so the books actually balance instead of approximately balancing.
- Fraud signals. Because dispense data is authoritative, the system can flag meter tampering and fuel shrinkage that standard reporting simply can’t see.
Under the hood
The interesting engineering isn’t the CRUD — it’s the accounting correctness. A cash-handling system that “mostly” balances is worse than useless, so the ledger is genuinely double-entry: every movement of money has two sides, and the station’s cash position is derived from the ledger rather than tallied up by hand. (Same principle I keep coming back to in my writing — derive from an authoritative source, don’t accumulate a running total and hope it stays in sync.)
Three roles — owner, manager, worker — each see a different slice: workers reconcile their own shifts, managers oversee the station, owners get the money-truth across everything. Getting those boundaries right (who can post what, who can only see) was as much of the design as the ledger itself.
And it’s fed by real hardware in a real shop processing real daily sales — which means the failure modes are real too: a controller that drops a reading, a shift that closes mid-transaction, a credit customer who pays half. The system has to stay correct through all of it.
Stack
Next.js · TypeScript · Python · PostgreSQL · AWS RDS. A TypeScript/Next.js front and application layer over a Postgres schema on RDS, with a Python service handling the pump-hardware integration and dispense ingestion.
Why it matters to me
Fuelnetra is the project I point to when someone asks what “product-minded” means. It isn’t a framework demo — it’s a system that a real business depends on to know whether its money is where it should be. Getting the accounting right, integrating physical hardware, and drawing the role boundaries so non-technical operators can actually use it — that’s the whole job, end to end.