Most software gets priced the same way. Somebody looks at two competitors, picks a number slightly below the cheaper one, adds two more tiers so the page looks normal, and that number then survives untouched for three years while the product doubles in capability.
It is understandable. Pricing feels like it should be a decision made once, at the end, by whoever in the room is least uncomfortable naming a figure out loud. It is actually a series of separate decisions, most of which matter more than the number itself, and several of which quietly determine what you end up building.
This is the fuller method: who the price is aimed at, what you charge per, how the tiers work, how to find the actual number, how VAT changes what you display in the UAE, and how to raise prices later without losing the people you already have. There is also a section at the end for businesses pricing an internal build rather than a product, because the same logic runs backwards.
Why cost gives you almost nothing
Start here, because it explains why pricing software is genuinely harder than pricing anything physical.
A physical product has a floor. Materials, labour, shipping. You know what it cost to make one more, so you know what you cannot go below, and that constrains the answer usefully.
Software's cost of serving one more customer is close to nothing. The floor is near zero and the ceiling is set entirely by what the buyer believes the outcome is worth to them, which is a judgement they make and you cannot inspect. Your accounts tell you almost nothing about where between those two the price should sit.
Use cost as a check, not a method. Add up what it genuinely costs to serve a customer, including support time and infrastructure, and confirm your price clears that with room to spare. That is a survival test. It is not a pricing method, and treating it as one is how software ends up costing a fraction of the problem it solves.
The customer does not care what it cost you to build and will not pay more because it was difficult. They are comparing your price against the cost of the problem they currently have, and that comparison is the only one that determines whether they buy.
Why copying competitors is worse than it looks
The other default. Also understandable, also weak.
A competitor's price reflects their cost base, their customer mix, their funding position and their history. None of those are yours. A well-funded competitor can price below cost for years; you cannot. A competitor with a large existing base can afford a low entry tier as a feeder; you may not have anywhere to feed.
Copying also chooses your strategy for you, and it chooses the worst one available to a smaller business. If your price is defined by reference to somebody else's, you are competing on price, and price competition is won by whoever can lose money longest.
What competitor pricing is genuinely useful for is understanding structure: what the market expects to be charged per, how many tiers people are used to seeing, whether annual discounts are normal. Structure is a convention worth respecting, because fighting it makes buyers work harder to understand you. The number attached to it is not a convention, and copying that is where the damage is done.
Who you are pricing for
One step people skip, and it makes every subsequent decision harder than it needs to be.
Before the metric, before the tiers, decide which customer the price is aimed at. Not in demographic terms, but in terms of the problem they have and what it currently costs them.
The reason this matters is that the same product can honestly be sold at very different prices depending on who is buying it. A tool that saves a two-person business four hours a month is worth a modest amount. The same tool preventing a compliance failure at a fifty-person company is worth considerably more. Neither price is dishonest. They reflect different problems being solved.
So write down, in one line, what the customer is currently doing instead. A spreadsheet and three people. A manual process that takes a day a week. A competitor's product they dislike. Nothing at all, and they absorb the cost.
That line is your reference point, because the customer's real comparison is never zero. It is whatever they are doing today, including the cost of doing nothing. A price that looks high in isolation frequently looks obvious next to a day a week of somebody's time, and it is your job to put the two side by side rather than hoping the buyer does it unprompted.
And it tells you when you are pricing for two customers at once, which is the source of most incoherent pricing pages. If your entry tier is aimed at a solo user and your top tier at a compliance team, those are different products with different sales processes, and pretending they are three tiers of one thing produces a page that persuades neither.
The decision that matters most: what you charge per
Before the number, decide the value metric. The thing you charge per.
Per user. Per transaction. Per property. Per invoice processed. Per gigabyte. Per location.
This is the most consequential pricing decision you will make, and most businesses never actually make it. They inherit per user because that is what the last product they used did.
Three tests for a good metric.
It tracks the value the customer receives. As they get more out of the product, they pay more, and that feels fair rather than extractive. This is what makes future increases defensible.
It is predictable. The customer can look at their own business and forecast the bill. Metrics that produce surprising invoices generate cancellations regardless of whether the amount was justified.
You can measure it honestly and show them. If a customer disputes the count and you cannot produce a clear breakdown, you have a renewal problem rather than a billing problem.
On per user specifically, which is the default: nothing is wrong with it and it is easy to understand. The difficulty is that it gives your customer a reason to limit who gets access, and limited access is exactly how software ends up unused. If your product gets more valuable the more people are in it, per user pricing taxes your own success.
Our guide on software nobody uses covers what happens when access is rationed for cost reasons.
How to choose: ask what actually grows as the customer gets more value. If it is people, per user is honest. If it is transactions, documents or volume, price on that. The question is not which is fashionable but which moves in step with the benefit.
And a consequence worth naming. Your value metric decides which customers are profitable, which decides whose requests deserve attention, which shapes your roadmap. Price per user and you build for teams. Price per transaction and you build for volume. Choosing the metric is partly choosing what your product becomes.
Metrics that cause arguments
Worth knowing the failure modes before you commit to one, because changing a value metric later is genuinely painful.
Metrics the customer cannot control produce resentment. Charging on something driven by your own system's behaviour rather than the customer's decisions means they receive a bill they could not have prevented, and they experience it as a penalty.
Metrics the customer cannot see produce disputes. If they cannot check the number themselves, every invoice is an act of trust, and trust erodes at exactly the wrong moment.
Metrics that spike produce cancellations. A busy month that triples the bill teaches the customer that their exposure is unbounded, and the rational response is to cap it by leaving. If your metric is volatile, put a ceiling on it, or move to bands rather than a strict per-unit charge.
Metrics that grow while the value does not are the slowest failure and the hardest to reverse. Charging for stored records when the customer's benefit comes from the records they actively use means the bill rises for data nobody looks at. The customer eventually notices, and the conversation is not a pleasant one.
Bands are frequently the practical answer to all four. Up to this many, that price. Up to the next, this price. The customer gets predictability, you get growth as they grow, and nobody is arguing about a count on an invoice. The cost is a small loss of precision at the edges of each band, which almost nobody minds and which is a fair trade for a bill that never surprises anybody.
Tiers: three, usually
Three is the standard answer, and it is usually the correct one.
One tier gives buyers nothing to compare against, and people evaluate prices comparatively. Two forces a binary yes or no. Four or more creates genuine decision paralysis and a stream of support questions about the differences.
Three lets you place an entry point, an obvious main option, and a larger one whose main job is making the middle look reasonable.
What goes where is the part people get wrong. The instinct is to sort by how impressive a feature is, putting the clever things at the top. The better rule is to sort by who genuinely needs it.
Things a small team does not need belong higher: granular permissions, audit trails, single sign-on, advanced reporting, service commitments. Our guide on access control covers why these are genuinely enterprise concerns rather than arbitrary gates.
Things everybody needs stay in the entry tier. Removing them does not create a cheaper product, it creates a product that does not work, and the customer who signs up for it churns having learned that your entry tier is a trap.
Free tiers and trials
A free tier is only worth having if free users become paying users through a mechanism you can name. They invite colleagues. They hit a limit that matters. They accumulate data they do not want to lose. If you cannot name the mechanism, you have a support cost with no upside attached.
For a first product, a time-limited trial is usually safer. It has a defined end, it forces a decision, and it does not commit you to serving people indefinitely.
On length: long enough for the customer to reach the moment where the product proves itself, and no longer. If that moment arrives on day two, a thirty day trial mostly provides time to forget you exist. Work out what a customer must actually do to see the value, measure how long that takes in practice, and set the trial slightly longer.
On requiring a card: requiring one reduces sign-ups and raises the proportion who convert. Not requiring one does the reverse. Neither is universally right. If your model depends on volume at the top of the funnel, do not ask. If each trial costs you real support time, asking filters out people who were never going to buy.
Finding the actual number
You have a metric and a structure. Now the figure.
Ask, but ask properly. "What would you pay for this" produces useless answers, because nobody knows and everybody understates.
Two questions work far better:
At what price would this be so expensive you would not consider it?
At what price would you assume something was wrong with it?
People can answer both honestly, because they are judging thresholds rather than committing. The gap between the answers is your realistic range, and the pattern across twenty conversations is more informative than any single response.
Ask the right people. Twenty conversations with people who match your intended customer beats a hundred responses from whoever was available. Pricing research contaminated by the wrong audience is worse than no research, because it produces a number you now feel confident about.
Watch behaviour as well as words. What somebody says and what they buy diverge routinely. If people say a price is fine and then do not buy, the price was not the answer.
On where to land: slightly higher than feels comfortable. Lowering a price is easy and customers welcome it. Raising one is hard and costs goodwill. A price set too low also attracts customers who chose you on price, who are the hardest to retain and frequently the most demanding, and who then anchor your expectations of what the market will bear.
And when nobody buys, establish whether the objection is genuinely price. "Too expensive" is the socially acceptable way of saying not convinced, do not trust you yet, or cannot see how this fits my work. Cutting the price when the problem is confidence loses the revenue without winning the customer.
The UAE specifics: VAT and display
This is where a pricing page that works fine elsewhere causes problems here.
Display prices inclusive of VAT for consumers. The price shown should be the price paid. Adding tax at the final step, after the customer has decided, is both a compliance exposure and a well-documented cause of abandonment. Our guide on consumer protection for online sellers covers the display obligations in full.
Business customers expect exclusive prices, because they reclaim the tax. If you sell to both, the two audiences need different displays rather than a compromise that satisfies neither.
On the rate itself: the default rate on a taxable supply of services in the UAE is five per cent, though a supply may be zero-rated where it falls within one of the zero-rating scenarios set out in the legislation [1]. Electronic services carry their own place of supply rules, and those rules differ between goods and services and depend on specific facts [1][2].
Selling across borders changes the treatment. For cross-border supplies of electronic services into the UAE, a reverse charge mechanism can apply where the supplier is not resident here and the recipient is registered or required to register for VAT [1]. The mirror question, what applies when you sell out of the UAE, depends on the destination and on your own position.
Have this checked before you launch internationally rather than discovering it in an audit. It is a short conversation with a tax adviser and an expensive thing to get wrong retrospectively.
On currency: dirhams if your customers are here. A price in local currency reads as a price; a price in dollars reads as a conversion, and it puts exchange rate anxiety into the decision at the worst moment. Dollars if you sell mainly abroad. Serving both with one currency means one audience is doing arithmetic exactly when you want them deciding.
Annual billing, and what it costs you
Annual plans at a discount are among the more reliable levers available. You receive cash earlier and hold the customer longer; they pay a lower effective rate. Two months free on an annual commitment is a common shape and an easy one to explain.
The cost is concentrated at renewal. A monthly customer whose card fails costs you one month while you recover them. An annual customer whose renewal fails costs you a year, and there is no second attempt next month to catch it. Our guide on failed payments covers the recovery process, which matters considerably more on annual cycles than monthly ones.
Give annual customers longer notice before renewal, confirm the amount and the date, and invite them to update the card. It is good practice, and it surfaces the customers who intended to cancel before the charge rather than afterwards as a dispute.
Discounting
Two rules cover most of it.
Never discount without receiving something. A longer commitment, payment up front, a reference, a case study, a design partnership. A discount given for nothing teaches the customer that your price is negotiable, and they will negotiate every time.
Never discount routinely. If everybody who asks receives one, your list price is fiction, and every sales conversation becomes a negotiation you have already partly lost. Worse, the customers who did not think to ask are now paying more than the ones who did, which is a difficult thing to defend if it ever becomes visible.
On founding customers, who will ask: granting a special rate is reasonable, and it should be paid for with something. The mistake is not the discount, it is failing to write down that it is a founding rate, what it covers, and how long it lasts. Two years later nobody remembers the arrangement, it looks like the standard price, and unwinding it is harder than agreeing terms would have been.
Publishing your prices
Publish anything a customer could reasonably buy without a conversation.
Hidden pricing filters out buyers who wanted to compare quietly, which is the large majority early in a decision. They look at what they can see, and you are not in the comparison. It also signals that the price depends on who is asking, which is true and unhelpful to say out loud.
Reserve "contact us" for genuine enterprise arrangements where scope really does vary. Even then, publish the lower tiers, so a visitor can work out whether you are within range at all before deciding whether to make contact. A range with a starting figure attached is far better than nothing, because it lets people rule themselves in or out honestly instead of guessing high and leaving.
Enterprise, implementation, and the things that cost you time
Enterprise pricing should start from what the smaller tiers imply, so the logic is visible and defensible rather than invented per deal. Then adjust upward for what an enterprise actually requires: security review, procurement, a negotiated agreement, support commitments, integration work.
Those consume real time. Absorbing them silently as a cost of winning is how a large logo turns into an unprofitable account. Our guide on technical due diligence covers the review side of what larger buyers ask for.
On implementation: if onboarding takes real work, charge for it separately. Bundling significant setup into a subscription hides a recurring cost and trains customers to expect unlimited help. A separate fee also improves outcomes, because customers who have paid for implementation attend the sessions in a way that customers receiving it free frequently do not.
Raising prices later
Two conditions, and both matter.
The product does substantially more than when the price was set. After eighteen months of development, your price reflects a product that no longer exists.
People are buying without hesitating. If deals are already hard to close, an increase is not the problem to solve first, and raising the price will simply confirm a difficulty you already have.
Raising prices because you need revenue, without having added value, is the version customers notice and resent. Most software businesses wait far too long rather than moving too early.
On execution: give notice, explain what changed, and decide deliberately about existing customers.
Grandfathering, letting them keep their original rate, is generous and popular and carries a real cost: every price change adds another cohort to support and another rule in your billing system. Five years of generosity produces a billing configuration nobody fully understands.
A workable middle position is grandfathering for a defined period, such as twelve months, then a single transition with substantial notice and a clear explanation. Moving customers over usually loses fewer than people fear, provided the reason is genuine and the notice is real.
Pricing an internal or custom build
Everything above assumes a product sold to many customers. A large number of UAE businesses are instead building something for themselves, or buying a custom build, and the pricing question inverts: not what should we charge, but what is this worth paying for.
The same logic applies, read backwards.
Work out what the problem currently costs, in hours, errors, delay or lost sales. Not precisely, but to an order of magnitude. Two people spending a day a week each on a manual process is a real annual number, and it is usually the first time anybody has written it down.
Compare that against the build cost plus running it. Software is not bought once. Add hosting, support, and the ongoing work of keeping it current. Our guide on technical debt covers why the second and third years cost more than the first if nobody plans for them.
Then ask what the cheapest version that solves the problem would cost. This is the question that most improves the economics, and it is rarely asked. A focused first version addressing the expensive eighty per cent of the problem frequently costs a fraction of the complete specification, and it tells you whether the remaining twenty per cent was ever worth building.
A note on how to read a quote. Quotes for the same brief routinely come back several times apart from each other, and none of them is necessarily wrong. They reflect different assumptions about scope, different amounts of contingency, and different views of what "done" includes. The useful response is not to take the lowest, it is to ask each supplier what they assumed, because the gap between quotes is almost always a gap in the brief. Our guide on writing a software brief covers closing that gap before the quotes arrive.
For reference, a scoped first version of a focused internal tool starts from around AED 15,000 with us, with larger multi-department systems costing more depending on integrations and compliance requirements. Final pricing depends on scope, and these are our own figures rather than a market survey.
What to watch afterwards
Four numbers tell you whether the pricing is working.
Conversion from seeing the price to buying. The headline measure.
Which tier people choose. If everybody picks the cheapest, your tiers are wrong: either the entry level contains too much or the middle does not justify itself.
How often discounts are requested. Constant requests mean the list price is not credible to the market you are actually selling to.
How long customers stay. A price that wins customers who then leave in four months has not won anything.
And one qualitative signal: if nobody ever hesitates at your price, you are too cheap. A price nobody questions is a price that was never tested against what the buyer actually thought it was worth, and the gap between those two numbers is revenue you agreed to leave behind before anybody asked you to.
Review properly once a year, plus whenever you ship something substantial. The review is cheap. The drift between what you deliver and what you charge is not, and it compounds silently.
The most common mistake
Charging too little, by a wide margin, and it happens for one specific and very human reason.
The founder knows how the product was built. They know which parts were straightforward, which were assembled from existing pieces, and how much of it was a weekend. So they price the effort.
The customer knows none of that and does not want to. They are weighing your price against the cost of the problem they have right now, and that cost is almost always larger than anything the person who built the solution would have dared to ask for.
Start with one sentence, written down where other people can see it: what do we charge per, and why that rather than something else. If you cannot write it, or if the honest answer is "because that is what the competition does", you have found the work.
If you want help with it, a pricing review covering your value metric, tier structure, willingness to pay evidence, and the billing and tax mechanics of implementing it starts from around AED 6,000 with us. Implementing the changes in the product and billing system is quoted separately by scope. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- Federal Tax Authority, e-commerce VAT guide
- The Official Portal of the UAE Government, value added tax
- Federal Tax Authority, VAT registration
- SKIMBOX, consumer protection for online sellers in the UAE
- SKIMBOX, subscription billing and failed payments
- SKIMBOX, when nobody uses the system you bought
- SKIMBOX, single sign-on and access control
- SKIMBOX, technical due diligence and what buyers examine
Tax treatment depends on your specific circumstances and on rules that change. Nothing here is tax advice; confirm your position with the Federal Tax Authority guidance or a qualified adviser before setting prices that assume a particular treatment.
