In production
Everything on this page runs today, at volume, in a live cash-on-delivery operation. The platform was not designed in the abstract and then sold — it was built inside the work, and every module in it earned its place by taking something off somebody's desk.
The conditions it is built for
High-volume cash on delivery, where the first question about an order is not whether it was placed but whether it will be accepted at the door. Several storefronts behind one warehouse. A catalogue that grows every week. A team that doubles in season and works in Arabic and English. That is a demanding set of conditions, and it is why the platform is hardened where it matters rather than broad and shallow.
The problem
A storefront takes orders competently and then hands over a list. Everything after that — deciding which orders to trust, printing them, picking them, handing them to a courier, taking the refused ones back, putting the stock away, and paying the people who did all of it — runs on spreadsheets, message threads and somebody's memory.
In a cash-on-delivery market that is not merely inefficient. A meaningful share of every batch comes back, the cost of it is real, and the information needed to predict which part is already sitting in the data — just nowhere anybody can act on it.
What it does
For every buyer, the share of their settled orders that actually got delivered — merging the duplicate profiles that are really one person behind a phone number and an address. It updates the moment anything happens to an order, and it has run continuously across more than 30,000 orders and 19,000 buyers.
When this is true, hold the order and do that. Score below a line, a genuinely first-time buyer, value above a threshold, four orders from one number in ten minutes, a name that is really a phone number. Written on screen by the person who noticed the problem, with nothing to wait for.
The hardest thing in the system and the least visible. One sale can reach you by more than one route, and counting it twice is the failure this kind of design is most prone to. It took a permanent record nobody can quietly edit, and a long tail of edge cases nobody would think to ask for, before a sale reliably counted exactly once.
Print the approved orders, pick from a list grouped by product, build the courier manifest, receive the returns, put the stock back — in the operation's own sequence, not ours. A stale-order rule retires an abandoned backlog quietly, without anybody having to delete anything.
Supplier photographs — usually whatever arrived on WhatsApp — become finished galleries in the house style and listing copy in the store's voice, categorised and drafted into the store. Seventeen style templates, measured from the catalogue rather than guessed. Spend capped monthly, identical work never billed twice, and a person approving anything generated.
Directory, attendance, leave, payroll, contracts and expenses — in the words the staff actually type, including free text in Arabic. All of it on iOS and Android from the same system, so a web release is on every phone the moment it goes out.
What it changes
The honest summary is that the operation stops losing information. Facts that used to be retyped between four places are entered once, and the decisions that used to depend on somebody remembering are made by rules that somebody wrote down.
Scoring is the piece with the clearest before and after: an order that will be refused at the door is flagged before it is picked, rather than discovered a week later when a parcel comes back.
What we learned
Any value only we can change is a value the operator has to ask us about. Deciding which values belong to the business is far cheaper at design time than after the fact, so now the question gets asked of every threshold as it is written.
The modules that give back the most time are the dull ones — expenses, attendance, the daily routine. Interesting to build and valuable to own are different axes, and only one of them belongs to the person paying. We sequence for the second one now.
Delivery status is read from the store, never from the courier. That single decision prevents a whole category of disagreement between two systems, and it is a default in the platform now rather than something each build works out for itself.
Not the feature list. The platform is shaped around the way an operation already likes to work, and every business rule inside it is handed to the owner as a setting. That is the product — the modules are only the evidence that we can build it.
The fastest way to find out is to tell us what this part of your operation currently costs you in people and mistakes.
Start a conversation