Built for how your trade actually runs.

Why this list is short

It would be easy to publish twenty industry pages. Most of them would be the same page with the nouns changed, and each one would be an implied promise that we understand a trade we have never served.

So there are five, and they are the trades whose actual requirements the software was built against. If yours is not listed, that is information rather than an oversight.

How the five differ in what they demand

Retail shops need speed at the counter and discipline around discounts. The software question is whether a discount ceiling stops a sale or merely records one.

Wholesale and distribution needs prices that vary per customer, credit enforced at the moment of billing, and transfers between locations that both ends agree on. Retail software with a customer list bolted on is not the same thing.

Pharmacies need batch and expiry handling as a hard requirement rather than a preference, plus unit conversion, because a box becomes strips becomes tablets and the arithmetic happens while somebody is waiting.

Schools and colleges need one student record from enquiry to leaving certificate, and they are also employers, which is why payroll sits on the same platform rather than in a separate spreadsheet.

Multi-branch businesses need consolidation. Each branch usually works; the group view is what does not.

If two of these describe you

They often do. A pharmacy chain is a pharmacy and a multi-branch business. A school group is a school and a multi-branch business. Read both pages: the requirements add rather than conflict, and the licensing is per register or per student either way.

Trades we are a poor fit for

Manufacturing with a bill of materials, project work billed on time rather than goods, and anything whose core process is a licensing regime we do not model. Restaurants sit in between: billing and stock work, but table and kitchen handling is not something we document, so we would not claim it.

We would rather lose an enquiry at this stage than at the demo, and considerably rather than in month six.

What we learned that changed the software

Each of these pages exists because a specific complaint kept recurring, and in several cases the complaint changed how the product works.

Expired stock reaching a counter was reported as a warning that cashiers ignored. The fix was not a better warning, it was blocking the sale, because a prompt read under pressure is a prompt dismissed.

Godown transfers that "went missing" were nearly always goods in transit with no name for that state, so both ends reported a shortfall. The fix was requiring confirmation at both ends before either position moves.

Defaulter lists being ignored turned out to be a staleness problem rather than an accuracy one. The fix was reconciling bank receipts against issued challans, so the list is right on the day it prints.

Choosing a starting point when several apply

Start with the one that is costing you money this month, not the one that is most interesting. A distributor with a receivables problem should not begin with batch tracking, however useful it will be later.

The systems are licensed per register, per student or per employee, so starting narrow costs less and teaches your staff on a smaller surface. Adding the second thing is a module you switch on, and the records you have already entered stay where they are.