All posts
7 October 2026

What a POS system should actually do for a small shop

Most shops do not lose money to theft. They lose it to not knowing what sold, what is finished, and whether the drawer balanced at closing. Here is what to insist on before you pay for any point-of-sale system.

A shop owner once told me he knew his business was doing fine because the shop was busy. He could not tell me which products made that money, which ones had been out of stock for two weeks, or why Saturday's cash was short by eleven thousand naira. The shop was busy. The business was leaking. A point-of-sale system earns its cost by answering those three questions every single day. Everything else is decoration. ## It has to be faster than the notebook This is the test most systems fail. If ringing up a customer takes longer than writing in a book, your staff will stop using it during the rush, which is exactly when the data matters. A sale should be three or four taps: find the product, confirm quantity, take payment, done. Watch the person who will actually use it. If they hunt for products, the search is wrong. If they cannot find a product by its everyday name, the catalogue was set up by someone who does not work the counter. ## Stock has to move when a sale happens Inventory that updates only when someone remembers to update it is not inventory. Every sale should reduce stock automatically, every delivery should increase it, and transfers between your shop and your store should be recorded as they happen. What you want out of that is one screen: what is low, what is finished, what has not sold in sixty days. The first two protect your sales. The third protects your cash, because slow stock is money sitting on a shelf. ## The drawer has to balance against something Open a shift, count the cash you start with, sell through the day, then count what is there at closing. The system tells you what should be there. The difference is a number you can actually ask about. Without shifts, a shortage is an argument. With shifts, it is a specific amount, on a specific shift, with a specific person who counted it. ## Every payment method needs recording separately Cash, transfer and card are three different stories. Transfers need checking against the bank, cards settle later, cash is in the drawer now. A system that lumps them into one total hides the one that is wrong. ## It must keep selling when the network drops This is non-negotiable in Nigeria and a good idea everywhere. If the system stops when the network does, staff go back to the notebook and you lose the day's data. The right behaviour is to keep taking sales locally and sync when the connection returns. ## Someone has to be accountable for changes Prices get changed. Discounts get applied. Items get voided. None of that is suspicious on its own, but all of it should be recorded with a name and a time. An activity log is not about distrust. It is about being able to answer a question six weeks later without guessing. ## What you can skip at the start Loyalty schemes, elaborate reporting dashboards, multi-currency, integrations with accounting software. Every one of them is reasonable later. None of them matters in month one, and chasing them is how shops end up paying for software they never finish setting up. Start with: fast sales, automatic stock, shifts and cash-up, payment methods split out, an audit log. Run that for a month. The next thing you need will make itself obvious, and it will be something I could not have guessed from here.

POSRetailInventory

Have something like this to build?

Tell me what the system has to do and who uses it, and you get a fixed scope, a timeline and a price before anything starts.

Start a project