Two ways of charging for the same software, and they produce different companies. This page explains what each model rewards, why per-seat pricing quietly keeps field staff off the system, and when paying per user is still the sensible choice.
Per-user pricing charges for each person who has a login, usually every month. It is the most common model in business software, it is easy to understand, and it scales down neatly: a team of four pays for four. Unlimited-user pricing charges for the software itself, often by how much of it you switch on, and then lets you add as many people as the business actually has.
The difference is not only arithmetic. Per-seat pricing puts a cost against every additional person, so every new login becomes a small decision. That decision is usually made the same way: office staff who obviously need it are given accounts, and the people at the edge of the business, field engineers, delivery staff, junior salespeople, part-time or seasonal workers, are left off. The system then holds a partial picture of the work, which is exactly the outcome the software was bought to prevent.
It is honest and predictable at small scale. A business with a fixed office team and no field operation knows exactly what it is paying for and can add a seat when it hires. It also makes vendors care about whether people actually log in, because a seat nobody uses is a seat that gets cancelled. For a five-person consultancy or a small inside-sales team, per-user pricing is often the cheaper and simpler answer, and there is no reason to avoid it.
The trouble starts where the headcount is largest and the individual value per person is lowest: the field. A technician who closes three job cards a day, a delivery driver who captures a signature, a junior salesperson who logs two visits a week. Each generates little revenue individually and each costs a full seat. So they share one login, or they carry on sending photographs to a chat group, or the office types their work in afterwards from memory. All three workarounds destroy the data the system was supposed to produce, and the loss is invisible because nothing ever fails loudly.
When people cost nothing to add, the question becomes who ought to be on the system rather than who is worth a seat. Every engineer gets the app, every visit is logged by the person who made it, every part fitted is booked by the person who fitted it, and attendance and location come from the people themselves rather than from a supervisor's reconstruction. The trade is that you are now buying capability rather than headcount, so the comparison shifts to which modules you need and whether you will use them.
Unlimited does not always mean unlimited. Ask whether all user types are included or only some, whether the mobile app counts separately, whether there is a cap dressed up as a fair-use policy, and what happens to the figure when you switch on another module. A model is only simpler if the questions it removes do not reappear elsewhere.
This is a question about the shape of your workforce, not about which vendor is cheaper. Answer these before you compare anything.
Aura Business uses the second model. Every plan carries unlimited users and is priced by module tier, with the three tiers described by how many of the 87 modules are switched on. That is a deliberate fit for the trades it serves, where the largest part of the workforce is in the field and is precisely the part that a per-seat model would leave out.
It is not automatically the right model for everyone. A business with six office staff, no field team and one narrow requirement may well be better served by a focused per-user tool, and this page is not an argument that capability pricing wins in every case. It is an argument that the pricing model decides who ends up on the system, and that decision is worth making deliberately. See how Aura Business is priced.
You pay for each person who has a login, usually as a recurring monthly or annual amount per seat. Adding a person adds cost, and removing one reduces it, which makes the model predictable for a stable office team.
You pay for the software rather than for the people using it, commonly by how much functionality you switch on. Adding staff does not change what you pay, so the decision about who gets access becomes an operational one rather than a financial one.
Often. A small office team with no field operation, or a business that needs one narrow tool used by a few people, will usually pay less per seat and get something more focused. The model only becomes a problem where headcount is large and spread out.
Because each technician or driver costs the same as an office user while generating far less measurable value individually. The rational short-term decision is to leave them off, and the result is a system that never sees the work happening in the field.
Every plan includes unlimited users. Plans differ by module tier, described by how many of the 87 modules across 12 suites are switched on, so adding field engineers, storekeepers or seasonal staff does not change what you pay.
Whether all user types are included or only some, whether mobile app users count separately, whether any cap exists, what happens when you add a module or a location, and how read-only and portal users are counted. Get the answers in writing.
Describe your setup in a message. We will say which option fits, even when that option is not ours.
Founder-led · Chennai, India · Built and supported by the person who wrote it