I built all of it alone, in eighteen months: the database, the accounting, the API and the screens. It handles their money, their stock and their tax. It has to be right every time.
A journal entry for a single sale, posted by the engine that every movement of money in the system goes through.
| Account | Debit | Credit |
|---|---|---|
| 1200Accounts Receivable | 1,240.500 | — |
| 4000Sales Revenue | — | 1,181.429 |
| 2300VAT Output Tax | — | 59.071 |
| 5000Cost of Goods Sold | 742.000 | — |
| 1300Inventory | — | 742.000 |
| Totals | 1,982.500 | 1,982.500 |
Rendered in code — not a screenshot.
Counted from the source tree on 13 September 2026, not estimated. See how each one was counted →
Each card gives the problem and the decision that had no clean answer. The full case study — what I owned, the architecture, the result and what I would change — is one click behind it.
Seventy-four places in the system move money. If one of them lands on the wrong account there is no error and no alert — the books are just quietly wrong until a year-end that will not reconcile.
When the system cannot find an account, guessing corrupts the books invisibly and refusing stops a shop trading. I chose the third answer.
The clients are retailers and some of them compete. In one shared database, a single forgotten line in a single query shows one shop its rival's prices — and on a test database with one client, every query looks correct.
One database per client makes that bug impossible to write rather than merely tested for. The price is that every migration runs twenty-plus times.
A till that refuses to sell when the connection drops is worse than no till at all. The hard part is not working offline — it is coming back online without losing or duplicating a single sale.
The receipt prints last, after the money is durably on disk. Every ordering decision in the write path falls the same way: fail in the recoverable direction.
Client names are withheld by agreement. The running system is demonstrated live on a screen-share, never handed over.
Full-stack or architecture, on a product where the numbers matter — ERP, accounting, invoicing, retail, payments, logistics. I am most useful where the domain is hard and the correctness bar is high, because that is the only kind of software I have built.
I want the one thing I have never had: a team. Seven years alone means nobody has ever reviewed my code. I have run written standards, staged rollouts and my own security audit as substitutes — but they are substitutes. Working somewhere that already has review and a test culture is most of why I am moving.
Availability
Immediately. No notice period to serve. Open to relocation.
I am happy to walk through any of the above on a screen-share — the live system, the posting engine, the sync design. Ten minutes tells you more than this page can.
Not ready to write yet?
The first opens the platform as something you can walk through module by module. The second is the same argument on three pages, if you would rather forward it to someone than send them a link.
Gazipur, Bangladesh · Open to relocation