The problem
Distributors, wholesalers and manufacturers in Algeria move goods on paper delivery notes. A note passes through preparation, dispatch, a depot transfer, delivery and sometimes a return. At each step, someone writes, signs or phones.
Nobody can see where a note is without calling around. Disputes about what was loaded, delivered or returned are hard to settle. The ERP knows the order but not the journey of the goods.
Cosmekarn, an Algerian cosmetics company, had this problem across several regions. Foxmayn Track started as the custom system we built with them.
Made to measure for Cosmekarn
We did not start from a template. We sat down with Cosmekarn's management, office and warehouse staff, on site and in many follow-up conversations, until the system matched how they work.
- Their roles and their steps. The statuses, the roles and who may move a note to which state come from their own flow. When they needed a loading manager between preparation and dispatch, we added the role. One person can hold several roles and switch between them in the app.
- Their regions. Parcels leave the main warehouse for regional depots and are delivered from there. Each regional step is a scan by the role that handles it.
- Their drivers' reality. A driver records a delivery, a return with its reason, or a rescheduled visit. The photo at the door, the offline mode and the in-app updates came from what drivers met on the road.
- Their barcodes. The scanner accepts their labels as they are printed, with or without the reference prefix.
- Their reports. The delivery-delay report follows the Excel template they already used.
After go-live we kept going in short releases. Each one was tried with their staff before it reached every phone.
What we built
Foxmayn Track follows each delivery note through its life. It has three parts.
- An API that holds the workflow and the rules.
- An admin console on the web for the office.
- An Android app for the people in the warehouse and on the road.
The people involved have roles: ADV (sales administration), preparer, shipping manager, driver, loading manager and admin. Each role can do only its own steps.
- Barcode scans move a note from one state to the next. The server checks the role and the transition on every scan.
- Proof of delivery is a photo uploaded with the delivery, with the phone's position at the door.
- Offline work. Drivers keep scanning without a signal. The app queues the scans and sends them when the network comes back.
- Dispatch and follow-up. The office assigns loads to drivers and follows each note in the console. A delivery-delay report exports to Excel.
- Updates in the app. Phones install new releases from inside the app, with no store.
- An ERP connector. Track reads your orders and delivery notes from your ERP through an adapter.
The interface is in French.
How it works
The code is a TypeScript monorepo. A shared domain package holds the statuses, the roles and the transition table. The API, built on Hono, Drizzle and PostgreSQL, uses that package to decide whether a scan is allowed. When a scan arrives, the API looks at the acting role and applies the transitions that role may perform. The phone cannot skip a step by sending a different request.
Offline, the phone offers the choices the role has, without asking the server. When the queue drains, the server checks every scan again, in order. A scan that is no longer valid is refused and shown to the person who made it.
The ERP side is a contract plus adapters. The workflow core knows only the contract. One adapter exists today, for the ERP of our first client. Adapters for ERPNext and Odoo are planned, not built.
The admin console is React 19 with Vite. The Android app is built with Expo and React Native and uses the phone camera for scanning. The release build is signed and versioned.
Where it stands
The system has been in production at Cosmekarn since August 2026. Their preparers, drivers and office staff use it every day, online and offline, and it is installed on their own server beside their ERP.
Foxmayn Track is the product we made from it. We moved the code into one monorepo, put the ERP behind an adapter contract and removed everything specific to one company. Cosmekarn still runs the first-generation build. Foxmayn Track runs as a hosted demo against a stand-in ERP, ready for a second client.
Honest limits:
- Only one ERP adapter exists, for the ERP of our first client.
- The interface is French only. There is no Arabic or right-to-left layout yet.
- The reworked product has not been installed at a client yet. The production experience comes from the first-generation build.
What we learned
Put the rules on the server. A scan is a request, and the server decides if it is valid. That keeps permissions the same on every client, online or offline.
A position is evidence, not proof. The phone sends its position with a delivery, and the office sees it. A phone can fake it and a fix can be off by hundreds of meters, so we never treat it as proof.
Automate the checks. Our CI runs type checks, lint, builds, unit tests, a database migration drift check, shell linting, a secret scan and a Docker smoke test against both databases and an ERP simulator.
Next
A second client, with the same work to fit their depots, their roles and their ERP. If you run distribution in Algeria and want to try it, see our other products or look at the Foxmayn Shopify Pay case study, also live at Cosmekarn.