The logistics platform beneath Jarida.
MCT is the engine: dispatch, compliance, clearing, warehousing, fuel and payroll in one system, with six role-scoped portals on top. Jarida is what it looks like in production. Your brand is what it looks like next.
Eight systems that already agree with each other.
Most operators run a dispatch tool, a spreadsheet for compliance, a broker's portal for clearing and a separate payroll package. MCT is one schema underneath all of it, so a delivered load is already a payable trip and a cleared entry.
Dispatch & loads
Load creation through to proof of delivery: assignment, work orders, checkpoints, exceptions and the document trail behind each leg.
Fleet & compliance
Trucks, trailers and drivers with document-expiry tracking, KYC packs and a hard dispatch gate that refuses to move a non-compliant unit.
Clearing & forwarding
Customs entries, border posts and duty positions on a working desk: transit medians, funnels and the documents each crossing depends on.
Warehousing
Receipts, putaway, picks and dispatch on a ledger that balances, with occupancy and dwell reported off the same movements.
Fuel
Purchase orders against supplier contracts, per-company service flags, consumption and forecast analytics, and a carrier payment ledger.
Payroll & workforce
Trip-based and salaried pay runs, recoveries, payslip PDFs and an audit-forged ledger the admin, carrier and driver surfaces all read.
Partner network
Assignments, bids and instrument-grade lane standards for third-party carriers, scoped so a partner sees only its own book.
Tracking & analytics
Live positions on one map, corridor and border intelligence, carrier scorecards and the KPI surfaces built on top of them.
Multi-tenant where it counts, in the database.
A white-label platform that separates tenants only in the interface is a data breach waiting for its first bug. MCT scopes at the row, so the portal, the API and the PDF renderer all inherit the same answer.
One codebase, many brands
Each deployment is its own project against the same application and the same schema. A tenant slug is the only thing that changes.
Row-level scoping
Access is enforced in the database, not just the interface. Every portal reads through policies tied to the signed-in identity.
Modules behind roles
Warehousing, fuel, payroll and the desks are catalogue entries. A role grants them; navigation and routes gate on the same grant.
Branding as tokens
Colour, wordmark and document furniture resolve from the tenant record. Nothing is hardcoded, so a rebrand is configuration.
Six audiences. One set of records.
Everyone in the chain gets a surface built for their job, reading the same rows. A driver's checkpoint is the client's tracking update and the admin's exception, without a sync step in between.
One engine. Your name on it.
A deployment is a project, a slug and a branding record. Colour, wordmark, favicon, email furniture and every generated PDF resolve from that record, which is exactly how this page is green rather than orange.
- Your domain, your logotype, your palette
- Documents and payslips carry your brand, not ours
- Modules switched on per deployment, not per fork
- Same schema, so upgrades reach every tenant at once