دفتري: دفتر الديون ونقطة البيع، بلا إنترنت

At a glance

The work, step by step

1. 01

   The problem

   In a small shop, debts live in a paper notebook. They get written fast, between one customer and the next, with no running total and no easy way to see how much is owed to you across all of them. When it is time to collect, the shopkeeper opens the notebook, reads the name, then opens WhatsApp and types the message himself. If the notebook is lost, so is the money, with nothing to point to.

   The software that is available usually assumes a live connection, a computer at the counter, and an English interface with Arabic patched on afterwards. That does not match a shop run by one person from a phone. The connection drops, the selling does not, and the ledger has to stay open either way.

2. 02

   What was built

   I built the product as one piece: a debt ledger whose statements leave as WhatsApp messages, a barcode point of sale with a shift cash drawer, inventory, installments, invoices and quotes. It runs on Android, iPhone, iPad, macOS and Windows, with a merchant web panel and an admin panel beside it, all Arabic and RTL first.

   The decision that shapes everything else is that writes happen on the device first: every sale or debt is stored locally the moment it happens, and reaches the server exactly once when the connection returns. I chose that because a shopkeeper may ring up ten sales before the network comes back, and not one of them may go missing or get counted twice. The screens are rendered from the app's own code (Flutter, Laravel, Livewire, Tailwind, with Playwright for the renders) rather than drawn as idealised mockups, so what you see here is what runs. One design system covers app and web, and it has a name: "the ledger and the receipt", the ledger for records and the receipt for movement.

3. 03

   The result

   2,524 backend tests passing

   This project has no user, download or revenue figures, and I am not going to put numbers in their place. What I do have in numbers: 2,524 backend tests and 2,346 app tests passing, and 44 reversible migrations rehearsed against a copy of the production database. Those measure that the system holds together, not that any shop earned more, and I state them with that limit.

   The measure that matters here is a different one: a full working day offline with no sale lost and none duplicated, checked by comparing what sits on the device against what reached the server after sync; the ledger matching the cash drawer at shift close; the time it takes to ring up a sale without pulling the shopkeeper away from the customer; and a statement reaching WhatsApp from inside the app without typing a message. Those are the numbers that belong in this section once they are measured.