Fleet Tracking in Belize for Buses, Vans and City Trucks

A bus operator in Belmopan once described his dispatch system to me as "three phones and a lot of shouting". That is still how most fleet tracking Belize businesses manage their vehicles: a driver calls in when he remembers, a supervisor guesses the rest, and customers phone the office to ask where the truck is. It works until it does not, and the cost of it not working is usually paid in waiting.

RideYa Tracker is the platform I built to replace that. It is real-time GPS vehicle tracking, built and run from Belize, and it lives at rideya.bz. GPS, for anyone who has not had to think about it, is the satellite positioning system that tells a device where on earth it is, the same one your phone uses for directions.

What RideYa Tracker actually does

A small tracking unit goes in each vehicle. It reads its position from satellites and sends that position over the mobile network, the same network a phone call travels on. My server receives those positions, stores them, and puts the vehicle on a live map that you open in a browser.

From there you can see where every vehicle is now, where it has been, and whether it is moving or stopped. No app store, no special laptop. A manager can have it open on a desk, a supervisor can have it on a phone in the field.

I have written up the engineering side of it in more detail, from the modules themselves through to the live map, in this post on GPS vehicle tracking in Belize, if you want to see what is under the bonnet.

How does GPS vehicle tracking work on a bus or delivery van?

There are three pieces, and it helps to understand all three before you commission anything.

The unit in the vehicle

I use low-cost GSM and GPS modules. GSM is the mobile network standard; these units carry a SIM card and send data over 2G, the older and slower mobile data service, which in Belize still has the widest coverage of anything. That matters more than speed. A position report is a few numbers. It does not need fast data, it needs data that works on the Hummingbird Highway.

The practical effect of using inexpensive modules is that per-vehicle cost stays low enough that fitting twenty units is a decision, not a capital project. That changes who can use tracking at all.

The part that receives the data

Positions arrive at an ingestion service I wrote using FastAPI, a Python framework for building the part of a system that receives and answers requests. Its job is unglamorous and constant: accept reports, check them, write them down, do it again. It runs on a server I maintain, hosted separately from my main server so that vehicle traffic never competes with anything else.

The map you look at

The map itself is a React application, meaning it runs in the browser and updates without you reloading the page. Vehicles move on it as they move in the world. You can follow one, see the whole fleet, or look at where a vehicle went earlier.

Can passengers and residents see the vehicle too?

Yes, and this is the part most operators do not expect.

RideYa Tracker supports route subscriptions. A rider, or a resident, can follow a particular route and see the vehicle assigned to it, without being given access to your whole fleet or your management screens.

For a bus operator, that means a passenger standing in Santa Elena can check whether the bus has left Benque instead of phoning the terminal. For a municipality, it means a household can see whether the garbage truck has passed their street yet.

That second case is not hypothetical. The Belmopan City Council runs CleanCity, a garbage-route tracker where residents watch collection trucks live. CleanCity is RideYa Tracker under a different name and different branding. The platform is white-label, which means the same software can be deployed with another organisation's name, colours and identity on the front of it. One system, maintained once, serving several organisations that never see each other.

You can read more about the platform and the deployments on the RideYa Tracker project page.

Who this suits in Belize

I built this for organisations of a size that exists here, not for a thousand-vehicle logistics operation in another country.

• Bus operators who want passengers to stop phoning, and who want to know which unit is running late before the complaints arrive.
• Delivery businesses moving goods between districts, where "it left this morning" is not a useful answer for a customer.
• Municipal services: garbage collection, water, road crews. Public visibility of a public service is worth a surprising amount of goodwill.
• Small mixed fleets: a hotel with shuttles, a hardware store with a few trucks, a contractor with vehicles at several sites.
• Anyone currently tracking vehicles on paper or by phone call, which is most of the fleets I have looked at.

Hosted product or custom build: which should you choose?

This is the real decision, and the honest answer depends on how unusual your operation is. A short checklist:

| If this is true | Then | | --- | --- | | You want vehicles on a map and history of where they went | The hosted platform does this already | | You want your own brand in front of it | White-label deployment, configured, not rebuilt | | You want riders or residents following routes | Already built in | | You need it joined to your billing, payroll or dispatch system | A custom layer on top of the platform | | You have reporting rules unique to your organisation | Custom work, scoped before anything is quoted |

Most organisations need the first three and think they need the last two. I usually recommend starting with what exists, running it for a season, then deciding what genuinely needs building. Software you have used for two months is much easier to specify than software you have only imagined.

What you own at the end

Whatever I build for you comes with source code, documentation and in-app help, and you keep ownership. I run my own Linux servers in Belize and have done since 2008, so there is a real person in the same time zone when something stops reporting. If you later want someone else to maintain it, nothing in my work prevents that. I think that is the only fair way to sell software to a business that will outlive the project.

Where to start

1. Count your vehicles and name your routes. Fixed routes, variable routes, or sites. This shapes everything else.
2. Decide who else should see the map. Managers only, or passengers and residents as well. Public visibility is a different conversation from internal oversight.
3. Check your coverage honestly. Where do your vehicles actually go, and does mobile signal reach there. Gaps are manageable but better known in advance.
4. Fit a small number of units first. Two or three vehicles for a few weeks tells you more than any specification document.
5. Write down the one report you would read every Monday. If you cannot name it, you do not need custom reporting yet.

If you would like to talk through how this would fit your fleet, you can reach me through the contact page. I am happy to tell you if the hosted platform is enough, which is often the case.