Fleetbase

Fleetbase is an open-source logistics and supply-chain platform: fleet dispatch and vehicle tracking in Fleet-Ops, headless delivery commerce in Storefront, warehouse operations in Pallet, invoicing and partner wallets in Ledger, and an extension marketplace on top. Operators self-host it or run it hosted, and reach it through a browser console, driver mobile apps, a REST API, a JavaScript SDK, and real-time WebSocket events.

That surface is spread across ten repositories: Laravel services, Ember applications, JavaScript and TypeScript SDKs, React Native mobile work, storefront products, and separate release paths. I had no prior Ember experience.

The earliest pull requests were small and infrastructural: dependency and formatting cleanup in fleetbase-js, organisation lookup, a package-publishing workflow, a release, a Node adapter fix. The next moved through storefront-js, the Navigator mobile application, and Storefront's application architecture.

That sequence built a map of how the product actually travels:

• SDK packages define the contracts products consume;
• applications consume those packages on different runtimes;
• Laravel services hold domain behaviour and validation;
• Ember packages supply shared components and extension points;
• release automation determines whether a fix reaches a user at all.

Without that map, a local fix can be correct in one repository and incomplete in the product.

A customisable widget-based dashboard needed coordinated work in three repositories:

• ember-core added widget registration behaviour;
• core-api added dashboard and widget services;
• fleetbase connected the capability to the product.

The visible feature lived in the application, but its contract and persistence belonged elsewhere. Treating it as one frontend ticket would have left the system split across incompatible assumptions.

This is the practical payoff of knowing the repository topology: knowing which part of a change should not be implemented in the file currently open.

A group of March pull requests moved component-context utilities into ember-core, then removed the duplicate local copies from FleetOps and Pallet.

The code change was modest; the architecture decision was not. Shared behaviour belongs in the package that owns the convention, not copied into every application that happens to need it.

The same principle applied across SDK typing, storefront rules, model reflection, package releases, Android fixes, customer and order views, permissions, and boot-screen behaviour: follow the product behaviour across repositories, then make the smallest coherent change at each boundary.

Accepted work across SDKs, package publishing, Laravel domain code, Ember extension points, storefront products, React Native fixes, dashboard behaviour, shared utilities, permissions, and releases, over a four-month engagement in a codebase I did not own.

The six unmerged requests are part of the record too. In external open source a change has to fit the maintainers' constraints, release direction, and review — which is a sharper feedback loop than measuring the work by how much code it produced.