A useful Saudi app budget separates the build from the cost of running it. Published offers span from a small two-store package advertised at SAR 3,999 to a supplier’s SAR 40,000–90,000 estimate for a booking app with payments and an admin panel. They describe different scopes, not a single market price. For a hypothetical bilingual booking product, the worked plan below sets aside SAR 103,000 before VAT for the build and 12 months of operation; it is a planning example, not a Hapy quote.
TL;DR
- One Saudi supplier advertises a two-store package from SAR 3,999; it prices custom integrations or accounts after a separate review.
- For a booking app with accounts, payments, and an admin panel, one supplier estimates 2–4 months and SAR 40,000–90,000; this is an estimate, not a quote.
- Our hypothetical booking-app example totals SAR 103,000 before VAT for the build and 12 months of operation, plus payment and app-store fees.
- If every line in that example is subject to 15% VAT, the cash total is SAR 118,450 before payment and app-store fees; actual tax treatment varies.
- Apple lists its developer membership at US$99 a year, and Google lists a US$25 one-time Play Console registration fee; local charges can differ.
- Choose a ready-made booking tool when its rules and data export fit; fund a custom app when a necessary workflow or integration cannot be handled reliably.
What does an app cost in Saudi Arabia?
For a straightforward booking business, start by comparing a ready-made product with a focused custom release. A package can be a sensible first choice when its booking rules, ownership terms, and export options fit. A custom app becomes more useful when a necessary workflow or integration cannot be handled by that product.
The figures below are public supplier claims checked on November 9, 2026. They are not a survey, accepted customer quotes, or a prediction of what your project will cost.
| Published Saudi example | Price and timing | What the figure describes |
|---|---|---|
| Ofq Tech’s two-store app package | From SAR 3,999; from 14 days after the required material is approved | The supplier says the package covers publication on both stores and a year of hosting and support. Custom integrations or accounts are priced after analysis. Check the contract for limits and tax. |
| Bateel’s booking-app estimate | SAR 40,000–90,000; 2–4 months | A supplier estimate for a service or booking app with registration, online payments, and an admin dashboard. The page does not establish a binding quote or every exclusion. |
| True Ventures’ app estimates | SAR 40,000–100,000 for a focused MVP; SAR 100,000–300,000 for a mid-sized app | The supplier describes the second range as a more developed app with payments and an admin dashboard. It is an indicative estimate, not a price list. |
The lower package and the booking estimates are not equivalent bids. The first names a starting offer; the others estimate classes of work. A low advertised price does not prove that an offer is inadequate, and a higher estimate does not prove better delivery. Compare the actual booking rules, data ownership, support, and exclusions before choosing.
What would a first-year booking budget look like?
In this hypothetical example, a Saudi service business needs an Arabic-English customer booking flow, one staff-facing admin panel, one payment integration, and apps for iOS and Android. The build includes design, backend, basic testing, and store submission. It excludes a separate provider app, live tracking, and a custom enterprise integration.
The amounts below are invented planning assumptions selected to show the arithmetic. The SAR 70,000 build assumption falls inside Bateel’s published booking estimate, but the supplier has not quoted this project and has not endorsed the other figures. The operating period is the first 12 months after launch; build work happens before it.
| Budget line | Assumption | SAR |
|---|---|---|
| Defined build | Design, two-platform app, backend, admin, payment connection, testing, and submission | 70,000 |
| Build contingency | 10% of the assumed build price | 7,000 |
| Support and maintenance | SAR 1,000 a month for 12 months | 12,000 |
| Hosting, monitoring, and messages | SAR 500 a month for 12 months | 6,000 |
| Translation and content | One allowance; the build includes the bilingual interface | 3,000 |
| Launch promotion | One allowance | 5,000 |
| Build plus 12 months of operation | Before VAT, store-account charges, and transaction fees | 103,000 |
If all SAR 103,000 of these assumed costs were subject to the standard 15% VAT rate, VAT would be SAR 15,450 and the cash requirement would be SAR 118,450. That is one tax scenario, not a conclusion about every invoice. ZATCA states that the standard VAT rate is 15%, with other treatments for some supplies. Your accountant can confirm which charges are taxable and whether input VAT is recoverable.
The example is useful because it stops a SAR 70,000 build figure from being mistaken for the whole budget. It does not establish a typical maintenance rate, hosting bill, or marketing cost. A business with higher message volume, a regulated workflow, or several payment and inventory connections needs a different model.
Which launch and operating fees sit outside the build?
App-store accounts, payment processing, hosting, support, and customer acquisition can sit outside an agency’s build price. Name the owner of each account and ask which fees continue after launch.
Apple lists the Apple Developer Program at US$99 per membership year, with local pricing where available. Google lists a US$25 one-time Play Console registration fee. These are account charges, not app-development prices. The actual local-currency charge, tax, and any applicable store commissions need separate checking.
Payment-provider charges change with the number, size, and type of transactions. For illustration only, 1,000 payments of SAR 100 each at an assumed 2% fee would cost SAR 2,000 before any fixed fees, refunds, or tax. That 2% is a calculation input, not a quoted Saudi rate. Ask your provider for its actual fees for mada, cards, refunds, settlements, and your sales mix before adding them to the budget.
Saudi Arabia’s central bank reported that electronic payments made up 85% of retail payment transactions in 2025. That figure includes retail payments beyond apps; it does not predict your customers’ preferred method. It does make it worth testing the payment methods your customers expect before you agree the integration scope.
Why do quotes for the same app differ?
The biggest difference is often the work each quote includes. Two teams can both promise a “booking app” while one prices a customer interface and the other includes the backend, staff permissions, failed-payment handling, testing, and support.
| Decision | Smaller first release | What expands the work |
|---|---|---|
| Booking | One customer journey and staff-managed availability | Multiple providers, dispatch, complex cancellation rules, or real-time location |
| Platforms | A shared iOS and Android codebase where device needs permit | Separate native implementations or platform-specific features |
| Languages | Arabic and English for the agreed customer and admin flows | Additional languages, large content migrations, or untranslated supplier content |
| Payments | One suitable provider and a defined payment flow | Multiple providers, refunds, marketplace payouts, or accounting integration |
| Operations | A limited admin panel with named permissions | Multiple roles, audit requirements, integrations, and round-the-clock support |
A shared codebase can reduce duplicated implementation, but it does not remove testing or store work on either platform. Choose separate native work when an important device feature or performance need justifies it. The cross-platform development guide explains that tradeoff in more detail.
Arabic is also more than translated labels. Set aside time to test right-to-left layouts, mixed Arabic and Latin text, phone numbers, forms, dates, and payment screens. The Arabic website guide illustrates the same direction and mixed-text issues; the actual app still needs testing on its target devices.
How long should you allow?
For the booking scope in Bateel’s example, the supplier estimates 2–4 months. Treat that as a planning reference for its described features, not a delivery promise. A project can take longer when translations, payment onboarding, integrations, review feedback, or the buyer’s approvals arrive late.
Put working milestones in the proposal: agreed scope and design, a testable booking flow, payment and admin checks, a release candidate, and store submission. The date for each milestone should state what the team needs from you. A stage-by-stage app plan helps connect those dates to actual decisions.
How do you compare offers fairly?
Send each team the same short brief. State the main customer journey, user roles, language needs, payment method, admin tasks, target platforms, and budget ceiling. Ask for a price and milestone for the same first release, then compare what is left out.
A useful proposal should show:
- The deliverables and acceptance checks for each milestone.
- Discovery, design, engineering, testing, and launch work included in the price.
- Hosting, messaging, store accounts, payment charges, translation, and tax that are billed separately.
- What the defect warranty covers, its duration, and the price and response terms for later support.
- Who owns the source code, design files, data, cloud account, and store accounts, including any licensed supplier components.
- How scope changes affect price and timing, and how the product can be handed to another team.
If a quote leaves the admin panel or payment failure handling out, add the missing work before comparing totals. Ask for a written change to the quote rather than assuming that a sales conversation added it. The MVP partner-vetting guide covers the ownership and delivery questions in more detail.
For personal data, map where it is collected, stored, accessed, and shared. Saudi Arabia’s personal-data guidance is a starting point for checking the relevant duties. Local hosting alone does not establish compliance; the actual data flows and your role matter. Include specialist review in the quote when the product or customer needs it.
If a standard booking product fits the first workflow and lets you keep the data you need, start there and test demand. If the booking rules or required connections are the product’s advantage, scope those parts for a custom release. Hapy’s MVP development team can help define that first release, including through its KSA service.
