Vehicle Tracking / CarView

01Business problem

Vehicle positions across warehouse, shed and yard were recorded in one person’s personal spreadsheet, invisible to everyone else. When that person was unavailable, the whole team lost visibility of where vehicles were held.

The need was to keep movement information organised, shared and traceable, at terminal locations where connectivity is not guaranteed and there was no budget for a hosted database.

02Existing workflow

Tracking here means quantity and movement records per location per day. It is not GPS tracking.

1. Vehicle movementsVehicles received into, and delivered out of, a storage location.
2. Operational recordOne entry per location per day.
3. Delivery / movement informationReceipts, deliveries and transfers between locations.
4. BalanceEach day closes with the prior balance adjusted by movements.
5. Search and trackingMonth navigation and a keyboard quick-navigation palette.
6. ReportingCharts, report sections and Excel export.

1. Private Excel fileOne person’s spreadsheet.
2. Shared operational systemInstallable, offline-capable.
3. Structured dataOne record per location per day.
4. ReportingThirteen report sections, Excel export.
5. AnalyticsSeven charts and summary cards.

The software is built around the process, not the other way around. Designed to reduce repetitive spreadsheet-based work.

03My approach

I kept the running-balance logic staff already used on paper, where a location’s day closes with the previous closing balance adjusted by that day’s receipts and deliveries, and made it automatic. Then I added what a personal file could not give: shared access, offline entry and a history of every change.

1. Real operational workflowDaily receipts and deliveries per location.
2. Business rulesCarry-forward balance, working days, transfers.
3. Structured dataOne dated record per location per day.
4. Calculation logicBalances recomputed from the records.
5. Web interfaceDaily entry, charts, reports, transfers.
6. ReportsReport sections and Excel export.

04System design

With no database budget, the data store is a private GitHub repository: every save becomes a version-controlled commit, which gives a full audit history without a database to host.

1. UserTraffic staff, on desktop or phone.
2. Installable web appOffline-first; entry works without a connection.
3. Business rules and calculationBalances and reports computed from the records.
4. Cloudflare WorkerAuthenticated writes; the GitHub token never reaches the browser.
5. Private GitHub data repositoryEvery save is a commit, with in-app version history and restore.

05Engineering trade-off

Why this architecture suits this workflow, and where it would not.

Constraint

A small departmental workflow, no budget for a hosted database, and terminals where connectivity is not guaranteed.

Decision

Keep structured data in a private GitHub repository, written only through a Cloudflare Worker that holds the token.

Benefit

Simple deployment, a full version history with restore, and controlled writes.

Trade-off

It is not a general-purpose database. It would not automatically suit a high-volume transactional system, which needs proper concurrency control and querying.

06Key features

• Daily entryAcross eight storage locations: warehouses, yards and sheds.
• Automatic balancesOpening and closing balances carry forward day to day.
• Rotation numbersInline-editable per row and included in exports.
• Car transfersBetween locations, with history; balances cascade forward.
• Holiday calendarWeekends plus a loadable Bangladesh government holiday calendar drive the working-day logic.
• Analytics chartsSeven charts plus summary cards.
• ReportsThirteen report sections with period filters.
• Excel exportFor anyone who needs the data outside the app.
• Version historyAny earlier version can be restored.
• Quick navigationCtrl+K palette for tabs, months, locations and reports.
• Offline-first PWAInstallable, with a card layout on phones.

07Technology

Frontend

HTML, CSS and JavaScript with no framework; installable PWA. Chart.js for charts, SheetJS for Excel export.

Backend

Cloudflare Worker for authenticated writes.

Data

Version-controlled JSON in a private GitHub repository.

Deployment

Cloudflare Pages.

Quality

Node test runner over the balance-calculation core.

Development

Git, GitHub, AI-assisted development.

08My role

1. Operations Specialist
2. Business Analyst
3. System Designer
4. AI-Assisted Developer
5. Tester
6. Deployer

• IdentifiedA single-person spreadsheet as the only view of vehicle positions.
• StudiedHow the department recorded vehicles by location and day.
• DefinedCarry-forward balances, transfers and working days.
• DesignedThe repository-as-data-store architecture and the Worker.
• BuiltThe app, with AI-assisted implementation under my direction.
• TestedBalance logic with automated tests and against real use.
• DeployedThe PWA and the Worker, then iterating.
• IteratedRefined through daily use by the department.

Built with AI-assisted implementation under my direction. I own the requirements, business rules, validation, testing and deployment; I did not hand-write every line, and AI did not decide what the system should do.

09Outcome

• A shared systemReplaced a single-person spreadsheet dependency with a shared, version-controlled system.
• Easier to manageMade operational information easier to search, review and report on.
• TraceableEvery change is recorded and any earlier version can be restored.
• In daily useUsed by the department across the tracked locations; exact daily usage is not logged.