Per-User vs Per-Module Pricing
Two pricing models with opposite incentives. Per-user pricing taxes the thing you want more of — people entering their own work. Per-module pricing taxes the thing that makes a system worth having — records that reference each other. How to read a quote in either shape.
Pricing models are not neutral. Whatever a vendor charges for, you will ration — quietly, without deciding to, through a hundred small choices made by people who are not thinking about pricing at all. That is why the model matters more than the number, and why the two dominant shapes in this market produce two quite different failure patterns.
What each model makes you ration
Per-user pricing
- You ration logins. The storekeeper shares an account with his assistant, the two branch managers use one seat, the night shift uses whoever is around.
- Which destroys the audit trail, because every entry now says the same name.
- Which destroys segregation of duties, because a shared account cannot be prevented from approving its own work.
- And it produces the specific pathology of one clerk keying everybody's movements — a digitised paper book with an extra step.
- Where it is honest: it scales with the size of the organisation, which is roughly how value scales.
Per-module pricing
- You ration modules. Inventory yes, procurement later, assets never.
- Which breaks the one thing an integrated system does that separate tools cannot: a payment that traces back to a receipt, an order, an approval and a request.
- Which is how businesses end up with the system they bought for inventory and a spreadsheet for buying — the exact position they were escaping.
- And the price rises at the moment you have least leverage, because you are already committed.
- Where it is honest: you genuinely do not pay for a payroll engine you will never switch on.
Neither is wrong. But they fail in different directions, and knowing which failure you are buying lets you compensate deliberately.
The shared-login problem is worse than it looks
Per-user pricing pushes businesses toward account sharing, and account sharing is the single most damaging thing that can happen to an operations system — not because of security in the abstract, but because it deletes attribution. An audit trail that names a shared account answers "who did this" with "somebody in the store", which is the answer you had before you bought anything.
And nothing detects it. In this system, and in almost every system at this end of the market, the only signal that a login is shared is counting active accounts against headcount and noticing the gap. It is not a technical control; it is an observation somebody has to make. Shared logins in Kenyan businesses goes into the detection problem properly.
The rule that follows from this
If a per-user price is making you consider sharing an account, buy the seat. A shared login costs you the audit trail, segregation of duties and the ability to attribute a mistake — and you are paying the subscription either way. Sharing a KES 525 seat to save KES 6,300 a year is a bad trade at any headcount.
How to compare two quotes in different shapes
-
Write down your year-three shape, not your year-one shape
How many people will need a login, and which modules will be live. Both quotes get priced against that, because both models are cheap at the start and diverge later — that divergence is the entire comparison.
-
Get the marginal prices, in writing
One more user in month eight. One more module in year two. These are the numbers that decide a five-year total and the numbers least likely to be in the proposal.
-
Ask whether adding one person forces a tier change
A tiered model with hard seat caps can turn one extra hire into a doubled subscription. Add-on pricing at the margin avoids that; ask which you are getting.
-
Check whether approvers need a paid seat
An approver who logs in twice a week still needs an account. Some vendors price a light approval-only role and most do not. This is where a per-user model bites organisations with many approvers and few operators — which is most Kenyan SMEs above about thirty staff.
-
Then compare on the year-three total
Not the monthly headline. Two quotes that look 40% apart on month one are frequently within 10% by year three, and occasionally reverse.
The same business, both models, year three
The per-module figures above are illustrative rather than a claim about any specific competitor — we do not have their price lists and would not publish guesses as facts. The point is the structure: two models that quoted similarly at the start can diverge by a month's subscription a year once modules and users have both grown, and the divergence is entirely predictable from the marginal prices you were quoted at the beginning.
Where we sit, and the honest downside of it
What AWRA OpsHub does today
- Per-user tiers with every module included — inventory, procurement, sales, POS, accounting, HR, projects, assets, helpdesk, reporting.
- Add-on users at KES 525 a month, so two extra people do not force a tier upgrade.
- Add-on employee records at KES 150 a month for payroll headcount above the plan.
- Annual billing at eleven months.
- Priced in shillings, which is the contract currency rather than a conversion.
What it does not do
- No light or approval-only seat. An approver who logs in twice a week costs the same as a storekeeper who lives in the system. For an organisation with many approvers this is our model's worst feature and we would rather name it than let you discover it.
- No usage-based option, so a very low-volume business subsidises a busy one on the same tier.
- No per-module pricing, so a business that genuinely only wants inventory pays for a platform.
- Non-user limits are tiered too — saved reports, workflow rules, webhooks and minimum schedule interval all move with the plan, which occasionally forces an upgrade for automation rather than headcount.
The last point catches people out: a business with six users and heavy automation needs may be pushed to Premium by the workflow limits rather than the seats. Price the automation you actually want, not just the people.
Our take
Price whichever model against your year-three shape, get the marginal prices in writing, and check whether one extra hire forces a tier change. Then compensate for whichever failure mode you have bought: under per-user pricing, refuse to share logins even when it is tempting; under per-module pricing, decide in advance which modules you will need and get them priced now rather than when you have no leverage.
Every module in the plan, users at the margin
Tiered on people rather than modules, with add-on seats so growth does not force an upgrade — and a plain statement of the one place our model is worse than the alternative.
See plans & pricingFrequently asked questions
Is per-user or per-module pricing better?
Neither, but they fail differently. Per-user pricing makes you ration logins, which pushes businesses into account sharing and destroys attribution. Per-module pricing makes you ration modules, which breaks the one thing an integrated system does that separate tools cannot — records that reference each other. Choose knowing which failure you have bought and compensate deliberately.
Why is sharing a login so damaging?
Because it deletes attribution. An audit trail naming a shared account answers "who did this" with "somebody in the store", which is the answer you had before buying anything. It also makes segregation of duties impossible, since a shared account cannot be stopped from approving its own work. And nothing detects it — the only signal is counting active accounts against headcount and noticing the gap.
How do we compare quotes with different pricing models?
Price both against your year-three shape — how many logins and which modules — rather than your year-one shape, because both models are cheap at the start and diverge later. Get the marginal prices in writing: one more user in month eight, one more module in year two. Two quotes that look 40% apart in month one are often within 10% by year three.
Do approvers need a paid seat?
Here, yes, and it is the worst feature of our model. There is no light or approval-only seat, so someone who logs in twice a week to approve costs the same as a storekeeper who lives in the system. For an organisation with many approvers and few operators — which describes most Kenyan SMEs above about thirty staff — that is a real cost and worth raising when comparing vendors.
Can automation needs force a plan upgrade?
Yes, and it catches people out. Saved reports, workflow rules, webhooks and the minimum interval a scheduled workflow may run at are all tiered alongside the user count. A business with six users and heavy automation requirements may be pushed to the top tier by those limits rather than by headcount, so price the automation you actually want rather than just the people.
