How to choose between a custom POS and an off-the-shelf one

A point of sale looks like a commodity until the first week of real trade. The question is not which product has the longest feature list. It is whether the till matches the way the shop already sells, takes money, and counts stock.

Start from the sale, not the brochure

Write down one ordinary sale and one awkward one. The ordinary sale is a single item, a standard price, and a card payment. The awkward sale is the one staff already know how to handle and software often does not: a split tender, a discount that only a supervisor may give, a return without the original receipt, or an item that is sold by weight.

If a packaged system covers both sales with settings you can understand, that is a strong argument for buying it. If the awkward sale needs a workaround, a note in a book, or a second spreadsheet, you are already paying for a custom process. You are just not paying for software that records it.

Count the cost of fitting the business to the tool

An off-the-shelf till is cheaper on day one. The cost shows up later, in the time staff spend translating the shop into the product’s language. Training, support tickets, and the monthly fee are real. So is the report that never quite matches the cash drawer, which someone then rebuilds in a sheet.

A custom build costs more before the first sale. You pay for discovery, a pilot, and the discipline of writing the rules down. In return, the screen can follow the counter you have, including the branch that sells differently from the others. You also own the code, which matters if the vendor of a package changes price or shuts a feature you rely on.

Ask what must work when the line is bad

Shops lose sales when the only record of a transaction lives on a server you cannot reach. If your sites have unreliable connectivity, offline selling is not a luxury. The device has to take the payment or record the order, print or show a receipt, and sync later without creating two versions of the same stock count.

Many packaged systems claim offline mode. Ask for a demonstration with the network unplugged, then reconnect and look at stock in two branches. If the vendor cannot show that path, treat the claim as unproven. A custom system should be held to the same test. The difference is that you can specify the conflict rules: which count wins, who is told, and what a cashier is allowed to do while the queue is waiting.

Decide with a short list

Choose a package when these are true:

• Your sales, discounts, and returns fit the product without a side process.
• You can live with the vendor’s release cycle.
• One or two sites are enough, or every site works the same way.
• You would rather rent the tool than own a codebase.

Choose a custom POS when these are true:

• More than one branch needs a shared stock picture, and the current reports are late or wrong.
• Staff roles matter: a cashier, a supervisor, and head office should not share one login.
• You need barcode receiving, purchase tracking, or a receipt flow the package cannot print.
• The business is the process. Changing the process to suit a product would cost more than the software.

Run a pilot before you commit the chain

Whichever route you take, pilot one counter. Run it beside the current till for long enough to compare totals, returns, and the end-of-day count. A week of a quiet branch tells you more than a quarter of demos.

If the package wins the pilot, buy it and stop. If it fails on the awkward sale or on a dropped connection, you have evidence for a build, and you have a written list of what the first release must do. That list is the scope. Everything else can wait until the counter is trusted.

The decision should stay yours, and it should be based on a shift you have watched, not on a feature matrix.