Home › Making it fit
Topic 5
Adapting a system to fit the shop
Every business believes it is unusual. Most are unusual in two or three ways that matter and ordinary in forty that do not. Telling those apart is most of the work — and getting it wrong is why systems get bought and then quietly abandoned.
Buy, configure, customise or build
Scroll sideways to see the whole diagram.
To define each, buying means purchasing a ready-made package from an outside company which is generally a quicker and cheaper option and can be running within a month. Configuring is setting parameters from a systems standard process to fit your organisation without customising the code. Customising is different to configuring as the organisation writes new code in software where the product does something it did not before, and every change must be managed. To build is when the organisation develops the software itself instead of purchasing where building could take months to years.
Most small businesses get hurt by customisation as it needs maintenance for the lifespan of the system, the cost of bug fixes, and regulatory upgrades are underestimated in the original business case. Every upgrade from the vendor also has to be retested against the custom code. For a shop with four staff members whose jobs are not related in IT, a freelancer would need to be paid and if they disappear the risk of nobody understanding the code, fixing bugs, and managing the software is high.
To recommend one, configuring would be the most suitable for a four-person shop as risks and costs associated with outside developers are low and with no IT specialist it is more beneficial compared to customising.
To configure effectively we can do a fit gap analysis where it is an evaluation that compares the operational requirements to what the software is capable of. We can do this by assessing the shop needs, evaluating what the product does, and how to fit the gaps. An example would be that the shop needs to sell by the metre, using a software called Lightspeed sets up the product by selling it by the unit of measure sold, fitting it into the business would be setting up pipe and cable as per metre products and the gap would be manual entry of the length.
Building custom software is only worth the cost when it benefits the business or if the business wants to differentiate on a process. If no product does it after evaluating the fit gap, then building one only if the shop can maintain it afterwards would be beneficial.
Where to bend the shop, and where to bend the system
Before shopping, split what the shop does into two lists. Most of the argument during an implementation is really a disagreement about which list something belongs on.
Bend the shop
Done this way out of habit, not advantage. Changing it costs a week of grumbling and nothing else.
- Invoice numbering and layout
- How the product list is categorised
- When the day is cashed up
- Which report the bookkeeper gets, and in what format
- Where a customer's details are captured in the conversation
Bend the system
How this shop actually competes. Force these to change and the shop loses something real.
- Negotiated contractor prices agreed by handshake
- Selling in part units — three metres of pipe, half a bag of sand
- Letting a known customer take goods now and settle Friday
- Trading through a power cut without turning customers away
- Serving customers in Setswana, Sepedi, isiZulu, English and Afrikaans across one counter
Bending the shop refers to administrative routines that do not affect the customer's experience, and bending the system refers to providing value to the customers that competitors cannot match. Applying a customer test can help distinguish between the lists, if a customer would not notice the change, then it is an internal habit, if the customer would then it is defined as a competitive advantage. The test has two parts, would the customer notice and would they go somewhere else if it changed.
The handshake pricing example gives a real advantage over competitors like giving discounts to loyal customers or rounding down a total if a customer is short by a few cents or rand by bending the system to allow for manual overrides avoiding the software to kill the relationship with the client. A system that forbids this will be bypassed within a week, so overrides should be allowed and recorded. The power cut example is a real issue in South Africa so using a cloud-based POS system where use will be lost during loadshedding and turning down customers because of it would mean that the system has failed the shop. The recommendation would be going for a POS system that has an offline first architecture.
In a multilingual country, your customers and staff would use words and phrases that are not only in English, and most software is in English. Bending the system by renaming categories in local languages helps the customer feel more welcome and speeds up transactions if the staff can use the software in their home language.
This is a business decision and not an IT one. Having an IT consultant make this decision means being suggested systems with cloud features, handshake pricing not being prioritised, and software being prioritised over the customer and staff. Having a list of non-negotiables for the system helps the store have an edge over competitors.
A worked example: the capture form
The demonstration's customer form is the argument of this page made concrete. It is generated from
one file — data/schema.js — which describes what a customer record contains.
Change that file and the form, the validation rules and the stored records all follow.
It adapts while you type
Choose "Business" and a VAT number field appears. Tick marketing consent and a date field appears, because POPIA now requires it. Choose cash-only and the credit limit disappears.
Asking a cash customer for a credit limit is inviting a wrong answer. The smallest correct form is the one that gets filled in properly.
It teaches at the right moment
Guidance appears next to the field it applies to, when it becomes relevant — not in a manual, and not in a training session three weeks before go-live.
Tick marketing consent and the POPIA note appears beside it, in one sentence.
It changes in one place
When the shop decides it needs to record something new — a delivery address, a trade category — that is one entry in the schema file.
Not a form change, plus a validation change, plus a database change, plus three places that were missed.
Progressive disclosure is when information is given only when it is needed. In a POS system this can be seen with a VAT number where the field is hidden unless a staff member explicitly selects it in the settings if a customer needs one. It reduces visual clutter and lowers any chance for errors in data entry.
More relevant forms get filled in more correctly, if the staff is forced to fill out a long form with irrelevant data to get past the validation it wastes time and causes inconsistencies in the data. Having an adaptive form that only allows for specific customer information depending on the type of customer helps with the correctness of the data.
We use a schema driven design, which means the customer is described in a single central file. The screen reads the file to draw itself, then the database reads it to store the record. If the store needs to start recording delivery zones, then it is changed in one place and the entire system updates. This makes the system cheap to modify as the business evolves.
The design is suitable for real world use, buttons are large enough to be tapped quickly with a finger or a mouse, the error messages are in English explaining what is wrong and it is not in computer code. The stock take sheet has the expected quantity removed. If the system tells the staff that there should be 50 bolts, then they will count 50 bolts. Hiding the number makes the staff answer honestly which makes the software fit the reality of the business.
The part that decides whether any of this works
They are abandoned because on a busy Saturday the book is faster, and nobody ever explained what the extra thirty seconds buys. Staff adoption is not a training problem. It is a design problem and a management problem, and it is where most small-business IT spending is actually lost.
Staff resist for rational reasons, if customers are lined up down an aisle on a busy Saturday, the staff will use what the fastest method is to avoid customer complaints. At first a new system is slower, and mistakes are more visible compared to a paper, so resistance is understandable. Involving the staff like Sipho and Thabo early on to get used to the new system and whoever learns the fastest can teach the other staff members. Focusing on returns or checking stock across aisles to make their day easier instead of solely focusing on the owners reporting is more efficient.
A system makes individual performance more visible which is uncomfortable for staff when seeing what each staff does is tracked. The best way to approach this is if Lerato explains what the system will and will not be used for such as understanding how a mistake happened or not punishing honest mistakes.
Making the right thing the easy thing instead of enforcing helps adoption of the system efficiently. If entering a specific department code requires going through multiple sub menus while the customer grows impatient, the cashiers will find a workaround.
When staff starts to enter false data to make the system save then the system will start to fail and will capture worse data compared to the book. This needs to be watched and the workflow needs to be assessed to see the reasoning behind it otherwise the digital system is no longer helpful.
Designing for South African conditions
| Condition | What it breaks | What to require instead |
|---|---|---|
| Load shedding | Cloud-only systems; anything that cannot take a sale offline | Offline capture that syncs when power returns, on a device with its own battery |
| Patchy or expensive data | Systems that re-download everything on every screen | Works on a slow connection; does not need video; tolerates dropouts mid-sale |
| Cash-heavy trade | Systems that assume every sale is carded and reconciled automatically | Proper cash handling, a cash-up that matches the drawer, and a record of who counted |
| Part-unit selling | Rigid product catalogues that only sell whole items | Units of measure that include metres, kilograms and bags — and decimals in quantities |
| Multilingual counter | Staff-facing screens and customer documents in English only | At minimum, plain English on documents. Ask what the vendor supports; do not assume. |
| Staff turnover | Systems only one person knows how to use | Short written procedures, and more than one person who can do every task |
| SARS and POPIA | Products built for another country's tax and privacy rules | Correct VAT handling, compliant tax invoices, and a way to answer a POPIA request |
South African conditions are not edge cases and are requirements a system needs to be judged on. In the Business Partners SME Confidence Index for the fourth quarter of 2025, 73.4% of small businesses said reduced load shedding had improved their operations (Lechman, 2026).
More research found that small enterprises in Klerksdorp had their operating costs raised due to loadshedding and financial losses occurred (Schoeman, van Wyk and Blaauw, 2024). A scenario to prepare for is when there is stage 4 loadshedding at 5pm on a Friday when the shop is the busiest. The shop needs offline capture that syncs when there is power again as cloud only systems would have the tills close. The shop also needs a battery and a 4G router, which are costed on the roadmap, and the paper book stays as the last fallback. In 2025 mobile data averaged R20.50 per gigabyte (StatRanker, cited in Bettencourt, 2026) so choosing a product that will work on a slow connection, does not have videos playing and does not have unnecessary syncs is important for the system.
Systems that assume every sale is card will fail if a third of transactions are cash. Proper handling to make sure that the transactions are balanced by the end of the day needs to be done such as having a float and a cash up that matched the drawer and a record of what was counted and by who so that any shortcomings can be traced.
Lechman, A. (2026). Power stability fuels SME optimism as seasonal trade falls short, survey finds. [online] IOL. Available at: https://iol.co.za/business-report/entrepreneurs/2026-06-16-power-stability-fuels-sme-optimism-as-seasonal-trade-falls-short-survey-finds/ [Accessed 12 Oct. 2026].
Schoeman, E., van Wyk, A. and Blaauw, D. (2024). Investigating the impact of loadshedding on Small, Medium, and Micro enterprises in Klerksdorp, South Africa. [online] Nwu.ac.za. Available at: https://repository.nwu.ac.za/items/1293852b-4fe1-4ba8-a3d3-03e145ef16ed [Accessed 12 Oct. 2026].
Bettencourt, D. (2026). South Africa pays more for data than 27 other African countries, new report finds. [online] Scrolla allAfrica.com. Available at: https://allafrica.com/stories/202602170116.html [Accessed 12 Oct. 2026].