The brief
A fuel station is a cash-and-stock business with thin margins and a lot of moving parts. Fuel pumped by the liter and merchandise sold across rotating shifts, tanks that have to reconcile deliveries-in against sales-out, and owners who need yesterday’s numbers this morning. Run several branches under a national fuel brand and the spreadsheets stop scaling. Fuel-Station Manager is the back office that holds it together, one system of record per operator, with reporting an owner can actually read.
What it handles
- Shift-based sales. Every receipt is tagged to a shift and an official-receipt (O.R.) number, with a customer, a payment method (cash, credit card, purchase order) and line items drawn from the brand’s catalogue. That covers fuels by the liter (biodiesel, the gasoline grades, kerosene), lubricants down to the individual SKU and pack size, and LPG cylinders by weight and valve type.
- Tank-level inventory. A dashboard of live gauges shows each fuel’s volume against tank capacity (e.g. 14,307 of 24,000 liters), backed by a product-availability table of quantities and current unit prices maintained through an item-price catalogue.
- Deliveries. Replenishment recorded per product line, which feeds the tank levels so stock-on-hand stays honest between sales and refills.
- Analytics & people. Per-product revenue statistics over any date range, summed across the catalogue, plus employee records and a full activity audit trail.
Money, including sale totals, quantities, unit prices, and fuel volumes, is carried as DECIMAL(12,4), so a ledger in the hundreds of millions of pesos still reconciles to four places rather than drifting on floating-point rounding.
How it’s built
Fuel-Station Manager runs on the studio’s config-driven white-label engine. Each operator is a separately deployed Laravel / PHP application on MySQL, and a single per-tenant config file drives everything that differs between brands. That includes not just the obvious branding (name, logo, theme colour) but the product catalogue itself. One brand sells one set of gasoline grades, lubricants and LPG types, another sells a different set, from the same codebase with no forks. Four such instances run simultaneously today, four brands, four deployments, one codebase to maintain.
Records soft-delete rather than disappear, every change is written to an activity log with the user, IP and payload, and access is role-gated so non-admins see only their own reporting windows. Onboarding a new brand is configuration, not a new build.
Why it matters
Four instances of this system run at once, one per fuel brand, and have since 2019. A single instance alone has logged more than 60,000 shift-tagged sales receipts, a book running into the hundreds of millions of pesos, correct to four decimal places the whole way. Across all four deployments that is north of 200,000 transactions quietly handled for the brands that depend on it, and still climbing. It’s deliberately unglamorous software, just Laravel, MySQL, and server-rendered reports, and that’s the point. Years of dependable, high-volume operation on a stack chosen for longevity over novelty. The config-driven white-label discipline behind it, four brands, one codebase, no forks, is the same one we carry across the studio’s portfolio. Boring, in production, at scale, for years is exactly the standard we build to.