What two years building dashcams and GPS trackers taught me about fleet profit

I spent about two years at Kasava building dashcams and GPS trackers for fleets, and the most useful thing that time taught me is uncomfortable for a hardware builder to admit: the device was rarely what fleet owners actually needed. They needed to know which trucks made money. This piece is what that lesson looked like from inside, and why it became Fleetric.

Key takeaways

• I worked for about two years at Kasava on fleet dashcams and GPS trackers, close enough to the hardware to respect it and close enough to customers to hear what it did not answer.
• The question fleet owners kept asking was not a tracking question. It was a money question: which vehicles, customers and routes are worth it.
• Tracking hardware reports movement; profit requires allocating cost and revenue against that movement. That is a software job the device cannot do.
• Second devices die in the field. Software that demands its own tracker next to the mandated one is the first thing unplugged when something misbehaves.
• That is why Fleetric is a pre-launch fleet profit intelligence platform for GCC fleets that reads mandated tracking feeds and computes per-vehicle profit, with no hardware of its own.

What did I actually build at Kasava?

At Kasava I spent about two years on fleet hardware: dashcams and GPS tracking devices, the physical boxes that go into working vehicles and have to keep reporting through heat, dust, vibration and drivers who did not ask for them. [AUTHOR: confirm the specific product lines and your role at Kasava, e.g. firmware, integration, product]

Building hardware for fleets is a good education because the field punishes wishful thinking within weeks. A device that demos beautifully still has to survive installation quality, power wiring, SIM coverage gaps and the simple fact that nobody in the truck cares about it. [AUTHOR: confirm one recurring field or installation issue you personally dealt with]

I am careful about the limits of this experience: two years in hardware is not twenty, and building trackers is not the same as running a 200-truck fleet. But it put me in the room, repeatedly, with the people who do run them.

What did fleet owners actually ask for?

The requests that stuck with me were almost never about tracking accuracy; they were about money and paperwork. Owners and coordinators would look at a live map, agree it was accurate, and then ask a question the map could not answer: which of these trucks is worth keeping? Which customer is worth the kilometres? Why did this month’s profit fall when utilisation went up? [AUTHOR: confirm a recurring customer question or conversation pattern from Kasava demos or support]

The pattern behind those questions was consistent. The data the fleet produced, positions, trips, ignition hours, was fine. What was missing was everything around it: fuel bills lived in spreadsheets, driver costs in payroll, insurance and registration in someone’s drawer, revenue in an invoicing tool. Nobody’s dashboard joined them, so the map stayed a map. [AUTHOR: confirm whether you visited customer operations in the Gulf or elsewhere, and roughly what fleet types they ran]

Why doesn’t hardware alone answer the profit question?

Because profit is an allocation problem, and allocation is not a sensor. A tracker, however good, reports where a vehicle is, when its ignition is on and how fast it moves. Profit per truck is revenue minus fully allocated cost: fuel, driver salary, insurance, depreciation, maintenance, tolls and fines, spread honestly across trips and vehicles. No firmware update turns the first list into the second; it is a cost allocation job that has to happen in software, against the movement data.

The second lesson is harsher and it is about architecture. In the GCC, tracking is often mandated: an approved OBU under Asateel in Abu Dhabi, WASL-connected devices in Saudi Arabia, SecurePath categories in Dubai. When a software vendor insists on installing its own tracker next to the mandated one, the fleet now runs two devices per truck, and the optional one is the first thing unplugged when a fuse blows, a SIM fails or an installer needs a wire. [AUTHOR: confirm this second-device pattern matches what you saw in the field at Kasava]

So the hardware taught me two constraints any honest fleet-profit product must respect: the mandated feed already carries most of the signal, and any architecture that depends on an extra box will quietly lose its data source in the field.

Why does Fleetric read existing feeds instead of shipping a device?

Fleetric reads existing feeds because that is the only design consistent with what the hardware years taught me. Fleetric is a pre-launch fleet profit intelligence platform for GCC fleets that reads mandated tracking feeds and computes per-vehicle profit. The device decision belongs to the mandate and the approved supplier lists; Fleetric’s job starts where the device’s job ends.

Concretely, that means:

• No second box. Fleetric ingests the feed your approved tracker already produces, or phone-GPS for vehicles outside the mandate, plus fuel-card and toll CSVs.
• Allocation as the core. Revenue minus fully allocated cost, shown as profit per truck, customer, project and site, in AED and SAR, in English and Arabic.
• Paperwork next to profit. Document and operating-card expiry tracking sits beside the profit view, because an expired card stops a truck as surely as a breakdown does.
• Pre-launch, said plainly. No production customers yet. The outcome figures on this site are illustrative, and the regulatory claims are dated and sourced because my memory is not a citation.

What does this mean for a GCC fleet choosing software in 2026?

It means splitting the decision in two and refusing to let any vendor blur it. The tracking decision is regulated: if you are in scope for Asateel or WASL, hardware comes from an approved supplier, and the compliance guides cover what each mandate requires. The profit decision is yours: whatever device the regulator put in your truck, the feed it produces can either sit in a map or become a per-truck P&L.

My bias is declared: I build the second layer. But the test I would apply to Fleetric or to anyone else in this space is the one the hardware years gave me. Does it need a second device? Does it read the feed you already pay for? Does it show profit per vehicle or just dots and alerts? If a coordinator can manage more vehicles without increasing administrative workload, the layer is paying for itself; if not, it is another dashboard. If you want to run that test on your own feed, book a 20-minute demo.

FAQ

Why does Fleetric not sell tracking hardware?

Because the founder spent about two years building fleet dashcams and GPS trackers and saw that the mandated feed already carries most of the signal a fleet needs. Adding a second device adds cost and a failure point without adding information; reading the existing feed is the architecture that survives real fleet operations.

Does fleet tracking hardware tell you which trucks are profitable?

Not by itself. A tracker reports position, ignition, speed and time. Profit per truck requires allocating revenue and cost, fuel, driver, insurance, depreciation, maintenance, against that movement data. That allocation is a software job the device cannot do, whoever manufactures it.

What is Fleetric?

Fleetric is a pre-launch fleet profit intelligence platform for GCC fleets that reads mandated tracking feeds and computes per-vehicle profit. It installs no hardware, reads the feed fleets already run for WASL, Asateel, SecurePath or IVMS requirements, and shows profit per truck, customer, project and site in English and Arabic.