Food import and wholesale trade — the local market · Deployed and running
Zad Al-Khair
An Arabic web system that follows an imported shipment from the order until its price is collected, and holds trade debt in gold instead of pounds so inflation does not eat it.
- System type
- Internal operations system (imports · inventory · credit sales · treasury · reports)
- Our role
- Full build — operations discovery, engineering, deployment
An internal operations system covering imports, inventory, credit sales, cash accounts and reports as a single chain: every clearing expense is posted as a ledger entry and immediately raises the landed unit cost, goods are sold out of a named inventory batch, and each invoice is measured in gold grams on its issue day and settled at the gold rate of each payment day. The interface is Arabic and right-to-left in its structure, and runs with the same capabilities on desktop and phone.
- 18
- screens
- 21
- database tables
- 44
- server actions
- 39
- indexes and unique constraints
- 11
- database CHECK constraints
- 27
- automated tests, all passing
- 12,318
- lines of code
- Sector
- Food import and wholesale trade — the local market
- System type
- Internal operations system (imports · inventory · credit sales · treasury · reports)
- Coverage
- 18 screens, 7 API routes, 21 tables
- Users
- Two roles: owner (all permissions) and staff (daily operation)
- Language and direction
- Fully Arabic, right to left (RTL) — not a translation layer over an English interface
- Devices
- Desktop and phone — the same system, with no cut-down version
- Currency and time
- Local currency · local time zone · Gregorian dates DD/MM/YYYY
The problem before the system
The trader imports 18 products — beans, rice, oils, spices and salt — from overseas suppliers as well as local ones. The problem was never selling. It was three gaps that cost him real money.
Read the detailHide the detail3 points
- The real cost of a shipment was unknown until it ended.
- — A single shipment passes through customs, the port quay, the chamber of commerce, the food safety authority and transport — each expense paid on a different day and recorded on a different sheet or spreadsheet. The true price per kilo only appeared once the papers were added up by hand, usually after the goods had already been sold at a price set by guesswork.
- The books were spread across separate notebooks and spreadsheets.
- — One notebook for customers, one file for shipments, another for expenses — and figures moved between them by hand. Every transfer was a chance to make a mistake, and there was no single truthful copy.
- Selling on credit lost its value silently.
- — The trader sells on 30 to 90 day terms. When the exchange rate and inflation move during the term, the same amount comes back with less purchasing power. His workaround was to convert the invoice into its gold equivalent on a calculator, write the number in the margin of the notebook, and redo the arithmetic by hand with every partial payment. The idea was right, but it was slow, error-prone, and nobody could audit it later.
Understanding the trade before writing the code
Read the detailHide the detail
We started from one question: what makes this business profit or lose? The answer was two numbers — the landed unit cost after every expense, and the value of a receivable on the day it is collected rather than the day it was issued.
So we built the system around those two numbers rather than around data-entry screens. Every structural decision serves one of them: shipment expenses are real financial entries attached to the shipment, so they appear in the cost and in the ledger at once with no double counting; and every gold conversion is stored at the rate in force the moment it happened, so today's price never changes a past effect.
The system is not a set of independent screens but one chain in which each link feeds the next: the shipment is ordered, clears the port, leaves it, enters the warehouse — each clearing expense being posted and added to the cost. Landed unit cost = (purchase price + all expenses) ÷ quantity. It becomes an inventory batch at that cost; a sale is made from a specific batch and the quantity leaves stock immediately; the invoice is measured in gold at issue — invoice grams = total ÷ the price of a gram of 24k that day; each payment settles at its own day's price — grams settled = amount paid ÷ the gram price on the payment day; and what remains is remaining grams, valued in pounds at today's rate.
The practical consequence: an invoice may be settled with more pounds than it was issued for, and that is correct. In the demo data shown, an invoice issued at EGP 297,500 was settled by two payments totalling EGP 305,800 — the difference is not a surcharge on the customer, it is the same weight of gold he took on the purchase day, priced on the payment day.
Arabic, RTL and responsiveness
The interface is fully Arabic and right-to-left in its structure, not by visual mirroring — and the system runs on a phone with the same capabilities.
Read the detailHide the detail4 points
- Navigation, tables, forms and printed documents are all built on dir="rtl" and logical properties (padding-inline-start rather than padding-left).
- Numbers, dates and codes are forced into Latin direction inside Arabic text so they do not flip.
- Wide tables scroll inside their own container instead of breaking the page, and navigation becomes a sliding side menu.
- A dark mode (the default) and a light mode are built on colour variables, and the choice is saved for the user.
Sales on the phone
The screens
32 screensThe software is real; the data shown in the screenshots is not. Every name and figure in these images is generated demo data: suppliers, customers, warehouses, bank accounts, phone numbers, tax numbers, amounts and gold prices are all invented, created on a completely isolated local database with no connection to the production database — which was never read. What is real: the software itself (a production build, with its screens, calculations and behaviour unchanged), the business name and logo, the product names taken from the business's real catalogue, the system-size figures measured from the repository, and the test results.
The full cycle — from order to collection
Importing and shipments
Selling linked to gold
Customers and suppliers
The ledger and the cash accounts
Governance and permissions
Printed documents
Signing in
Light mode
What changed
| Before | After |
|---|---|
| A shipment's cost was added up by hand after it ended | The landed unit cost appears instantly with every expense posted |
| Linking an invoice to gold on a calculator, redone with every payment | Conversion and settlement happen automatically, and every rate used is kept as a fixed record |
| Data spread across separate notebooks and spreadsheets | One truthful copy: 21 linked tables behind 18 screens |
| Knowing who was late meant going through the notebook | Late accounts are flagged automatically with the number of days late and sorted first |
| The cash balance was a mental estimate | A balance derived from the movements themselves, with a running statement that can be checked line by line |
| A backup whenever someone remembered | An automatic copy every dawn, keeping the last 60 |
Before
A shipment's cost was added up by hand after it ended
After
The landed unit cost appears instantly with every expense posted
Before
Linking an invoice to gold on a calculator, redone with every payment
After
Conversion and settlement happen automatically, and every rate used is kept as a fixed record
Before
Data spread across separate notebooks and spreadsheets
After
One truthful copy: 21 linked tables behind 18 screens
Before
Knowing who was late meant going through the notebook
After
Late accounts are flagged automatically with the number of days late and sorted first
Before
The cash balance was a mental estimate
After
A balance derived from the movements themselves, with a running statement that can be checked line by line
Before
A backup whenever someone remembered
After
An automatic copy every dawn, keeping the last 60
This table describes a change in capability — what the system is now able to do — not measured gains. There is no documented before/after measurement of time saved or errors avoided, so no percentage is claimed.