---
title: "How DriveStream's fuel tracker got built"
description: "Fuel tracking was item three in DriveStream's first prompt. Here's how it went from a list item to a feature visible across the whole convoy."
date: "2026-09-23"
app: drivestream
kind: build
readingTime: "5 min read"
image: "/img/build/drivestream/fuel-log.jpg"
imageAlt: "DriveStream's fuel tab showing tank level, range, km/l and logged fill-ups"
---

Fuel tracking was item three in the list of four things DriveStream was supposed to do. It was sandwiched between the convoy map and the walkie-talkie, and in the early sessions it got less attention than either of them. It turned out to be one of the most practical things in the app — the feature that, on a long drive, is most likely to prevent an unplanned stop on the side of the road.

This is how it got built.

## What the first prompt asked for

On August 23, the first session scaffolded the entire app from a single list. The fuel portion of that prompt read:

> Add fuel informatino everytime we reful, cost and how much liters, auto detect petrol bunk and store the details and estimate / show the mileage / km/l of the car with this data

That's a full-featured fuel ledger in one sentence. Each fill-up logged with cost and volume. The petrol station detected automatically. An economy figure computed from the running history. What came back from that session was a fuel tab, a logging flow, and the km/l calculation — the structure of what the app has today.

The starting assumption was that the useful number is km/l: it tells you how far your tank will carry you, and it gets more accurate the more fill-ups you log. The prompt also imagined automatic detection of petrol stations, which would remove the manual step of opening the app when you pull in. That piece turned out to require trade-offs worth examining.

## Taking it further: the range problem

A second prompt in the same session extended what the fuel tracker could start with:

> also in fuel if possible ask for remaining r ange if available most cars show it in the dashboard which the user can enter to get initital state if required they can either put range left or liters left

This was a practical observation about how drivers actually know their fuel state. A car's dashboard typically shows remaining range in kilometres, not the volume left in the tank. A driver setting up the app might know they have 200 km of range but not how many litres that corresponds to, because modern fuel gauges show the distance estimate, not the raw volume.

The prompt asked for either number to work as a starting point. What came back handled both: when you set up your car, you enter either remaining range or remaining volume, and the app converts one to the other to initialise your economy estimate. The starting state matters because a km/l figure calculated without it will be wrong for the first fill-up cycle.

![DriveStream's fuel tab showing tank level, range, km/l and logged fill-ups](/img/build/drivestream/fuel-log.jpg)
*The fuel tab shows tank level, remaining range, km/l and each fill-up in the log.*

## The OBD-II path not taken

A few days later, a different direction came up:

> I am planning to add obd support to get the car details, wht do you think ? [Image #35] do you think we can integrate with this ?

The image showed an OBD-II Bluetooth dongle — the hardware you plug into a car's diagnostic port to read engine data directly. The question was whether DriveStream could skip manual fuel entries altogether and pull tank level from the car itself.

The assessment that came back was thorough. OBD-II dongles vary in quality, protocol support and reliability, particularly over Bluetooth. iOS Bluetooth handling adds its own constraints for background access. And fuel level, while standard in the protocol, is one of the more inconsistently implemented parameters across car manufacturers: some cars expose it accurately, some expose it in chunks, and some don't expose it at all.

The simpler path — you log a fill-up when you stop at the pump — turned out to be enough. The manual log is one tap, the data is accurate because it comes from the pump itself rather than a sensor reading, and it works on every car without needing additional hardware. The OBD-II conversation clarified what the automated version would cost in complexity, and that clarification was useful even though the answer was no.

## What fuel adds to a convoy

The more interesting design question about fuel tracking is that it's shared. Each car's fuel level and remaining range are visible to every other car in the convoy.

![DriveStream's drive summary with route map, distance, speed and time stats](/img/build/drivestream/drive-summary.jpg)
*A drive summary after reaching the destination, with route, distance, moving time and top speed.*

The reason is straightforward: a group road trip fails when one car runs low without the rest of the group knowing. Coordinating a fuel stop on a moving convoy is hard enough; coordinating an emergency stop is harder. If every car's range is on the map alongside its position and speed, the group can decide when to stop before anyone is coasting in on reserve.

The prompt didn't frame it this way — fuel sharing was implied by the app being a convoy app, not called out as a specific decision. But it follows from the same logic as showing speeds above each car: the information is most useful when everyone has it.

## What's in the tab now

The fuel tab shows four things: the current tank level as a percentage, the remaining range as a distance, the running km/l figure, and the log of fill-ups with date, volume and cost.

![DriveStream's convoy map with the walkie-talkie on and "You talking" visible](/img/build/drivestream/convoy-map-talking.jpg)
*The convoy map during a drive with the walkie-talkie in use.*

The tab's data feeds two views: the detail view for the driver's own car, and the summary that appears alongside each car in the convoy list. Drivers in the convoy don't see each other's costs or full logs — just the level and range — which is the number that matters for deciding when to pull over.

The feature that looked like the quietest item on the first list turned out to produce five concrete things: fill-up logging, cost tracking, economy estimation, range calculation, and convoy-wide visibility. Each one came from the initial prompt or the follow-up on the same day, and none of them required a major redesign afterward. Fuel tracking was the one part of the first spec that worked roughly as described and needed iteration rather than rethinking.

[DriveStream](https://drivestream.app) is in beta for iPhone on iOS 26.