Logistics & Import Management Platform
AlSalam International
An import-operations platform that tracks shipments, suppliers, companies and product registrations in one system, with role-based access, reports, a public QR verification page and full Arabic/English RTL support.

Overview
A platform that brings import operations into one system: shipments, suppliers, companies and their documents, products and their registration progress, with reports and role-based access, in Arabic and English.
My role
Frontend developer at AI Cloud. I architected the application and its data layer, built the business modules, and implemented the bilingual interface.
Key features
- Shipment tracking with five statuses: Ready to Ship, In Transit, Arrived, Delivered and Delayed.
- A product registration pipeline from Draft through Submitted to Committee, Under Review, Sample Requested and Trial Stage to Approved and Registered, with requirements tracked per product.
- Company records with documents, locations and an activity history, alongside supplier and employee management.
- A public product verification page that needs no login, and a downloadable QR code image for each product.
- Roles and permissions: every protected page declares the permission it needs, and users without it see a no-access page.
- Thirteen report cards, including delivered, delayed and upcoming shipments, product performance, supplier history, imports by country and missing documents.
- Excel export from the main lists: companies, suppliers, employees, products and registration requirements.
- Configurable settings: product categories, registration requirements and reminder templates.
- A full Arabic and English interface with RTL layouts (over 1,600 labels in each language).
Screens
Architecture
Data access is layered so the UI never talks to an API directly.
- UI componentsPages and shared components.
- ServicesWhat the UI calls for business operations.
- RepositoriesOwn data access behind a single interface.
- Mock or live APIA single environment flag chooses which one a service uses.
Why it is built this way
- Screens can be built and tested against mock data, then switched to the live API without changing UI code.
- A clear separation between UI, business logic and data access.
Technical deep dive
Repository, service and mock layering
Each service picks a mock or HTTP repository from an environment flag, so features can be developed and demonstrated with realistic data and later pointed at the real backend.
Permission-based routing
Routes carry the permission they require (13 distinct permissions across the app) and a guard checks it before the page opens.
Public product verification
The verification page sits on its own public route, outside the authenticated area, so it can be opened without an account.
Bilingual RTL/LTR
Arabic and English share the same screens, with matching translation keys in both languages, using ngx-translate.
Testing
The code base includes 78 unit-test files, run with Vitest.