Retail — appliance sales on instalment · Deployed and running
Installment System
A complete system for running instalment sales at an appliance showroom — from the customer's request to the last instalment, with every approval step and every pound in between.
- Client
- An appliance showroom (not named) — The showroom is not named anywhere in this package.
- System type
- Full internal operations system
The showroom sold on instalments with no system: paper notebooks for the contracts and schedules, Excel files for follow-up, and a hand calculator for every sale. This system puts the whole cycle in one place — request, investigation, manager approval, contract execution, instalment schedule, collections, treasuries and stock — where each step unlocks the next, balances are derived rather than typed, and every change writes an audit row with a before/after snapshot.
- 67
- Database tables
- 51
- API routes
- 250
- Server actions
- 61
- Permission keys
- 26
- Pages in navigation
- 97,855
- Lines of code
- 1,063
- Commits
- Sector
- Retail — appliance sales on instalment
- System type
- Full internal operations system (requests · contracts · collections · treasuries · stock · reports)
- Coverage
- 26 pages in the app · 51 API routes · 67 database tables
- Users
- Showroom staff in different roles: manager, cashier, investigator
- Language
- Arabic throughout, right-to-left, with Eastern Arabic numerals (٠-٩)
- Devices
- Desktop and mobile — the same system, not a cut-down version
- Timeline
- 26 January 2026 to 5 July 2026 (1,063 commits)
The problem before the system
The showroom sold on instalments with no system. The work was spread across three things at once: paper notebooks for the contracts and the instalment schedules, Excel files for follow-up, and hand-calculator arithmetic for every sale.
Read the detailHide the detail5 points
- No single correct number
- — The treasury balance was on one sheet, the receipts in an Excel file, and what the client still owed in a third notebook. A simple question like "how much is left on this client?" meant opening three sources and reconciling them.
- The instalment was recalculated from scratch every time
- — Appliance price, down payment, administrative fees, margin by term — all of it on a hand calculator, and any multiplication slip stayed in the contract until its last day.
- Collections ran on memory
- — Who is late today? The answer was flipping through pages, so whoever was late stayed late until somebody happened to remember them.
- Responsibility was not on the record
- — Who took this money? Who approved this request? Paper does not answer.
- Staff floats grew unnoticed
- — Nobody noticed, because there was no number updating in real time.
The approach
Read the detailHide the detail
Before any code, the first job was understanding how the showroom actually works — not how it is supposed to work.
Selling on instalment is not a transaction, it is a relationship that runs for up to 20 months. The system has to hold that whole relationship: the appliance, the guarantor, the instalment schedule, every payment, and every follow-up call.
Trust is the real product. The showroom hands over goods against a promise. So the investigation, the guarantor and the trust receipt are not paperwork formalities — they are the substance of the business, and they have to be mandatory steps in the system rather than optional fields.
Money comes in through more than one door — cash at the showroom, a digital wallet, and collection out in the street. Any system that does not unify those paths into one understandable treasury will leave a gap.
Staff will not drop their work to fill in data. Any screen that takes longer than the paper did will not get used.
Arabic and responsiveness
Not a translation — Arabic by design from the start. The whole layout is right-to-left, and displayed numbers are Eastern Arabic (٠-٩) through a global converter that runs before paint so there is no flash of Latin digits.
Read the detailHide the detail5 points
- Wide tables scroll inside their own container and the page itself never scrolls sideways.
- Field font size is large enough that mobile does not auto-zoom when typing.
- Height uses dynamic viewport units, because of the browser bars that move on Android.
- It installs as an app: there is a manifest and icons, so staff add it to the home screen and open it without a browser bar.
- Collecting outside the showroom runs on the same complete system on mobile, not a reduced version of it.
Logging in from mobile
The screens
28 screensEvery name, number and amount in the screenshots is fully generated demo data, produced on a separate, disposable local database instance with a seeded random generator. There is no real customer data and no real amount, and no real figure was rescaled — so the showroom's actual numbers cannot be inferred from these images. The showroom's own identity (name, address, phone, wallet number) was written into the source code in 40 files, including logo SVGs that hold the name as text; it was substituted in the copy that the captured build came from. Before every shot the page text is swept, and a check rejects the shot outright if any forbidden string is found — no image was written to disk without passing that check.
Daily work
The request cycle — from submission to execution
Treasuries and money movement
Client files and instalments
Stock and suppliers
Permissions and audit
The same screen in different roles
What changed
| Before | After |
|---|---|
| "How much is left on this client?" — open and reconcile three sources | One number on the screen, derived from the instalments |
| Calculating the instalment — on a hand calculator every time | One formula, the same number in the calculator and in the contract |
| Who is late today — flipping pages from memory | A work list ordered by what is due |
| Who took the money / who approved — not recorded | An audit log with actor, time, and the value before and after |
| Treasury balance — worked out at the end of the day | Derived live from the movements |
| Manager approval — verbal | A gate locked in the code; no execution without it |
| Collecting outside the showroom — paper | The same complete system on mobile |
Before
"How much is left on this client?" — open and reconcile three sources
After
One number on the screen, derived from the instalments
Before
Calculating the instalment — on a hand calculator every time
After
One formula, the same number in the calculator and in the contract
Before
Who is late today — flipping pages from memory
After
A work list ordered by what is due
Before
Who took the money / who approved — not recorded
After
An audit log with actor, time, and the value before and after
Before
Treasury balance — worked out at the end of the day
After
Derived live from the movements
Before
Manager approval — verbal
After
A gate locked in the code; no execution without it
Before
Collecting outside the showroom — paper
After
The same complete system on mobile
The operational impact here is described in terms of what became possible, not in performance figures — because the showroom's real operating numbers are not measured here, and were deliberately not measured.