This is a field guide to fintech app sama compliance for the Saudi market. No theory you can't act on, and no advice that assumes a US search landscape.
Building an app for this market means solving RTL properly, localising the store listing, and budgeting for the maintenance that keeps it shippable. Most failed apps in the Kingdom failed on one of those three.
Why this matters commercially
The commercial case for fintech app sama compliance in Saudi Arabia rests on a simple comparison: what a qualified enquiry currently costs you through paid channels, against what the same enquiry would cost once this work compounds. In most categories we see, the organic and owned-channel figure settles well below the paid one within a year — which is why this is a margin decision as much as a marketing one.
Release and support economics
Budget for the ongoing cost, not just the build: OS updates twice a year, store policy changes, SDK deprecations, security patches, device fragmentation testing and support. A realistic annual maintenance figure is a meaningful percentage of the original build cost. Applications that skip this become unshippable within eighteen months and require expensive rescue work.
Decide native versus cross-platform on requirements
React Native and Flutter now cover the majority of business applications at meaningfully lower cost and with one codebase. Go native when you need deep platform integration, sustained high-performance graphics, or specialised hardware access. For a Saudi audience, note the mixed iOS and Android split — iOS carries disproportionate purchasing power in major cities while Android dominates by volume — so both platforms genuinely matter from launch.
Arabic and RTL in mobile applications
Both platforms support RTL layout, but support is not the same as correctness. Test navigation transitions, gesture direction, list ordering, date pickers, number formatting and mixed-direction strings. Ship with a native Arabic type ramp rather than a scaled Latin one. Most Arabic mobile experiences fail in the details, which is precisely where users notice.
Typical project shape
| Stage | Typical window | What you should see |
|---|---|---|
| Discovery and prototype | 2–4 weeks | Validates whether an app is the right answer |
| Design including RTL | 3–5 weeks | Both directions designed together |
| Build and integrations | 8–16 weeks | Backend and third-party systems dominate |
| Store submission and review | 1–2 weeks | Plan for at least one rejection cycle |
Windows assume consistent execution and a market of ordinary competitiveness. Treat them as planning ranges, not commitments.
Retention is designed, not added
Most apps lose the majority of users within a week. The fix is onboarding that delivers value in the first session, notifications that are relevant rather than promotional, and a reason to return that is built into the product. Push permission should be requested after you have demonstrated value, with a clear statement of what the user will receive.
Measurement is not reporting. Reporting describes what happened; measurement changes what you do next.
Forms: ask for less, get more
Every field you add costs completions. Name, phone and one open field is usually enough to start a conversation; qualification can happen in the call. Support Arabic input properly, validate Saudi mobile formats without rejecting valid ones, offer WhatsApp as an alternative to the form entirely, and confirm submission with a message that says what happens next and when. Silent success screens are why prospects call competitors.
Budget allocation that survives a bad quarter
A workable starting split for a Saudi mid-market company: roughly 40% to demand capture — search, remarketing, marketplace presence — where intent already exists; 35% to demand creation across social and content; 15% to owned assets, website, email and CRM; 10% to experiments. Review quarterly against pipeline, not impressions, and move money towards whatever is producing qualified conversations.
Strategy is a set of refusals
A plan that lists every channel is not a strategy. Decide the two audiences you will serve, the three channels you will actually resource, and the things you will not do this year. Saudi mid-market teams routinely spread a modest budget across seven platforms and achieve presence without performance on any of them. Concentration is uncomfortable and it is what produces results.
RTL is a layout system, not a text direction
Setting dir="rtl" flips text and starts the argument. Navigation order, breadcrumbs, progress steps, sliders, form alignment, icon direction, chart axes and animation origin all need deliberate decisions. Meanwhile numerals, telephone numbers, email addresses, currency codes and Latin brand names stay left-to-right inside a right-to-left sentence. Use logical CSS properties — inline-start and inline-end rather than left and right — and the two directions can share one stylesheet honestly.
Practical checks before you sign anything off
- Validate that the job genuinely needs an app rather than a fast mobile site
- Confirm mixed Arabic and Latin strings render correctly in every component
- Plan for two OS releases and associated SDK deprecations per year
- Budget annual maintenance as a meaningful percentage of the build cost
- Ship a native Arabic type ramp rather than a scaled Latin one
- Test on low-end Android devices, not only current flagships
- Deliver a useful outcome within the first session
Content-first, not template-first
Design around real copy, real product names and real image assets. Layouts built on placeholder text collapse when Arabic headings run longer than the English mock or a product name has fourteen words. Ask for the content before the visual sign-off; it changes the design, and it changes it far more cheaply at that stage than after development.
Measure pipeline, not activity
Impressions, reach and engagement describe effort. Qualified enquiries, cost per qualified enquiry, pipeline value and closed revenue describe outcome. Instrument the handover between marketing and sales properly — source captured on every lead, status updated in the CRM, revenue attributed back — or every budget conversation becomes an argument between two sets of unconnected numbers.
Where to start this week
Before commissioning a build, validate that the job genuinely needs an app rather than a fast mobile site or a progressive web app. If it does, localise the store listing properly from day one and budget the first year of maintenance alongside the build — that number changes the business case more than the development quote does.
If you take one thing from this: measure the baseline before you change anything. Everything else on this page becomes arguable without it, and unarguable with it.
