Software built in Riyadh, in Arabic first
Enterprise applications for government entities since 1999, with Arabic text, names and mixed-script data treated as requirements to test rather than a localisation pass at the end.
Industries
A ministry or authority asks two questions before any product is named: what can stay inside the Kingdom, end to end, and who runs it after the programme ends. This page answers both with capabilities the site already publishes, and is careful about what it does not claim.
Sector guide Published 6 min read
01The two questions
Public-sector technology programmes in Saudi Arabia are shaped by two constraints that private-sector pages tend to treat as footnotes. The first is residency: for many classes of data the answer to “where may this run” is inside the Kingdom, and sometimes inside systems the entity itself operates, and that answer decides the architecture before any feature does. The second is continuity: a programme is delivered by a contractor for a term, and the system it delivers is used for a decade, so the question of who operates it after handover decides whether the programme succeeded.
Interkey’s answer to the first is that every practice on this site can be deployed in-Kingdom, on infrastructure the entity controls where the classification requires it. Its answer to the second is that Interkey operates what it implements, from Riyadh, on the Saudi working week, and hands over runbooks an entity’s own team can follow if it prefers to run the system itself.
02End to end
The layers of a typical programme, the in-Kingdom option for each, and who operates it. Which layers must stay is answered by the entity’s own data classification; this table says that every one of them can.
| Layer | In-Kingdom option | Operated by |
|---|---|---|
| Where workloads run | In-Kingdom region, local provider or the entity’s own infrastructure, decided per data class; the cloud practice works through the options | The entity, or Interkey on an agreed scope |
| The application itself | Built in Riyadh by the software practice, Arabic as a first-class requirement, source and artefacts owned by the entity | Handed over with documentation, or maintained under agreement |
| Telemetry and monitoring | Observability with the telemetry kept in-Kingdom; the residency guide covers the three deployment models | The entity’s operations team, or the managed service |
| Citizen and staff notification | Interkey Digital Connect for OTP and notification traffic, with sender-ID registration as a process | Interkey as the platform provider; the entity owns the content and the rules |
| Facilities and sites | SquintPRO safety and zone monitoring on existing cameras, with footage processed on-premise where it must not leave | The entity’s facilities team, with Interkey tuning and operating the detection |
| Integration with national platforms | Interfaces to sector and national platforms on those platforms’ terms, with any data in flight held in-Kingdom | A named owner per interface, which is the deliverable |
03What Interkey brings
Enterprise applications for government entities since 1999, with Arabic text, names and mixed-script data treated as requirements to test rather than a localisation pass at the end.
Every platform Interkey implements has an in-Kingdom deployment shape, and the classification decides which shape rather than the vendor’s default.
The practice most programmes leave unfunded: platforms operated on the Saudi working week from Riyadh, or handed over with runbooks the entity’s own team can follow.
04How it runs
The sequence is ordinary; what is specific to the sector is that the first and last steps are the ones most often skipped.
Every class of data the programme touches mapped to where it may live, from the entity’s own policy. Everything else follows from this and nothing is safe before it.
Where each layer runs, which platforms, and what the in-Kingdom shape costs to operate, decided in writing before the build.
The application, the platforms and the interfaces to national and sector systems, tested on real Arabic data and cut over incrementally rather than on one weekend.
A named operator for every platform in year three: the entity’s team with runbooks, or Interkey on an agreed scope. The programme is not finished until this is decided.
Eligibility, local content and references are the buyer’s to establish
This page names no government entity as a customer. It states no local-content position, because that is an assessed figure under the buyer’s rules and not a supplier’s assertion. It claims no accreditation, registration or procurement eligibility: whether Interkey qualifies for a given programme is established through the entity’s own process, and a page that implied otherwise would be describing a decision that is not its to make. What Interkey can state is capability, and that is what is on this page.
05Arabic first
A government programme is specified, reviewed and operated in Arabic, and a supplier whose engineers, documentation and support run in English with a translation layer is a supplier the entity is working around. Interkey delivers from Riyadh in Arabic and English: the requirements workshops, the user-facing application, the runbooks and the operations team.
The same applies to the data. Arabic names, addresses and identifiers, in Arabic script and in transliteration, are the normal case in any citizen-facing system, and matching them across systems is where integrations in this sector actually fail. It is tested during the build on real local data, which is a stated part of the scope rather than an assumption.
Scoping a programme where the data must stay inside the Kingdom and someone must run the result for years? Interkey designs to the classification and operates what it builds, from Riyadh, in Arabic.
06Buyer questions
Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.
Yes. Every layer in the table above has a shape that runs on the entity’s own infrastructure, at the cost of operating it. Whether that shape is required for a given layer is answered by the entity’s data classification, and the cloud practice works through the options where a class of data is allowed a wider choice.
Whoever the programme names, and naming them is part of the scope. If it is the entity’s own team, the handover includes runbooks written from the system as built and enough transfer that the team can follow them. If it is Interkey, the managed service takes the platforms on an agreed scope with a defined way back in-house.
This page makes no claim either way, on purpose. Eligibility for a given programme is established through the entity’s own procurement process, and a supplier stating it on a web page is describing a decision that belongs to the buyer. Ask, and it will be answered in the procurement conversation with the documents that conversation requires.
No. References for public-sector work are given in conversation with the counterparty’s consent, and not on a web page. A sector page that names entities as customers without that consent is claiming something it has no right to claim.
Delivered in Arabic. The user-facing text, the data model that has to hold Arabic names and identifiers correctly, the documentation and the operations reporting are produced in Arabic by the Riyadh team; English is the second language, not the source one.
From the insights library
The three deployment models and where each puts the entity’s telemetry, written to survive an auditor’s review.
PracticeEnterprise applications built in Riyadh since 1999, for government entities among others.
PracticeOperation after handover: the scope, the agreement and the way back in-house.
Solutions for this sector
Next step
Describe the programme, the classes of data it touches, and who is expected to run the result. The design conversation starts there, before any platform is named.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia