Blog Overview
Our published band is SAR 10,000 to 25,000 over 10 to 16 weeks. What “one app” means, the seven factors that raise the number, and what the quote leaves out.
When a Saudi company requests a mobile app quote, it usually gets three numbers with no shared definition: one for a simple app with a single screen, one for an app with payments, notifications, and an admin dashboard, and one for an app with users, roles, reports, and ERP integration. All three are called “an app,” but they are three different products.
This article breaks down our published band, what pushes the number above it, and what it costs to operate the app after launch. The figures are published, not estimated. The goal is to know what you are buying before you sign, not to get a number that pleases you today and costs twice as much a year later.
What “one app” means
Inside the published band, “one app” means one complete flow: sign-up and sign-in, a home screen, one core action, a success state, an error state, and one notification. It also means one app on one platform, or two platforms through a shared framework. It does not mean five flows, three roles, and a full admin panel.
The difference between a “screen” and a “flow” is the first thing to understand. A screen is part of a flow. A flow starts with an intent, ends with an outcome, and passes through loading, error, and empty states. A twenty-screen app may contain only two flows, and a six-screen app may contain five. Pricing by screen hides that difference.
The factors that raise the number
Seven factors cover most of the difference between one quote and another. Each can be planned for, but its effect cannot be hidden.
| Factor | What it adds | How to control it |
|---|---|---|
| Platform count | iOS and Android need separate testing and release | Start with one platform, or a shared framework with real testing on each |
| Roles and permissions | Each role needs navigation, states, and tests | Start with two roles; defer the rest until usage proves them |
| Offline operation | Sync, conflict resolution, and weak-network testing | Ask whether the user genuinely needs to work offline |
| Payments | Gateway integration, invoices, refunds, and security testing | Use an approved Saudi provider from the start |
| ERP integration | APIs, synchronisation, and error handling | Define fields and directions before design |
| Compliance and privacy | Consent, encryption, retention policy, breach reporting | Write the requirements into acceptance criteria |
| Store review | Rejection or delay pushes work back a week | Read the store guidelines before the build, not after |
What the quote leaves out
Four lines appear after launch. First, store accounts: an annual Apple developer account and a one-time Google account. Second, notifications and cloud services: they grow with the user count. Third, maintenance: OS updates, bug fixes, and new device compatibility. Fourth, user acquisition: an app does not acquire users just by being published.
Ask about each line before signing. An app with no operating budget is a project that stops after six months and leaves angry users and bad reviews. Worse, reviving it costs more than building it the first time.
From reading to shipping
Want this built, not just explained?
Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.
iOS and Android: one platform or two?
The decision follows your audience, not your preference. If most users are on iOS, start there. If they are on Android, start there. If the audience is split, a shared framework lowers cost, but it does not remove the need to test each platform on a real device. Shared code does not mean a shared experience.
For the full comparison, read Flutter vs React Native in 2026. The short version: the choice depends on your team and performance requirements, not on framework popularity.
What discovery produces
Discovery is not a question-and-answer session. It is two weeks that end with five files: a flow map, a screen list with states, an integration list with an owner for each system, an interactive prototype of the core flow, and a written scope with a fixed price and a list of deferred decisions. Those files are what make a quote comparable, because they turn “an app” into defined work that can be measured.
If a vendor refuses to quote before discovery, know that it is selling a guess. If it gives you a fixed number without those files, you will later discover that everything unwritten is a change request. Discovery costs money, but it is cheaper than building the wrong flow for three months.
Before you request a quote
Write the core flow in one sentence. “A customer books a service, pays, and tracks the status” beats “a services app.”
Pick the first platform. iOS or Android, with the reason. Do not start with both unless the audience is genuinely split.
Bring five users. Names or roles we can speak to during discovery.
Name the integrations. Payment, ERP, ticketing, or maps. And name who owns each system.
Write the sector requirements. Privacy, data retention, hosting, and consent.
Agree the operating budget. Stores, cloud, maintenance, and support for a full year.
Ask about code ownership. Who owns the repository and accounts at the end of the project?
Read the store guidelines. Especially the minimum-functionality and duplicate-app rules.
Frequently asked questions
Is SAR 10,000 enough for a full app? It covers one complete flow on one platform, or two through a shared framework. A full product needs a larger scope.
How long does it take? The published band is 10 to 16 weeks, including design, build, testing, and release.
Does the price include store release? Release is included. Store accounts and fees belong to the owner.
Native or shared framework? It depends on performance, device requirements, and your team. The comparison article explains the difference.
What happens after launch? A clear maintenance contract: OS updates, bug fixes, crash monitoring, and user support.
Sources
- Apple App Store Review Guidelines — rule 4.2 on minimum functionality and 5.1.1 on privacy.
- Google Play developer policies — release requirements and data safety.
- Flutter documentation — app structure and performance.
- React Native documentation — the new architecture and compatibility.
- Mobile app engineering — our scope and work.
