Building custom software for a Saudi business is not very different from building it anywhere else. The engineering is the same. What changes is the context: data protection law, Arabic as a first-class language, a handful of national systems you may need to integrate with, and clients who expect local support.
This is the checklist I would hand to any engineer starting a custom software project for a Saudi client. It is based on the kind of work a software development company in Saudi Arabia does day to day: internal tools, ERP modules, customer portals, and AI features.
One note first. I am an engineer, not a lawyer. Where the law is involved, treat this as a starting point and confirm details with your client's legal counsel and the official sources.
Start with the data, not the screens
Saudi Arabia's Personal Data Protection Law (PDPL) is overseen by SDAIA. Before you design a single screen, list what personal data the system will hold, why, and where it will live.
A simple data inventory saves weeks later:
Field Purpose Lawful basis Retention Leaves KSA?
Full name Account Contract Account life No
Phone OTP login Contract Account life No
National ID Identity check Legal As required No
Keep this table in the repo. It becomes the source for your privacy notice, your retention jobs, and your answers when the client's compliance team asks questions.
2. Record consent as data
If the system relies on consent, store it as a first-class record with a timestamp and the exact wording version the user saw:
CREATE TABLE consent_records (
id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL REFERENCES users(id),
purpose TEXT NOT NULL, -- e.g. 'marketing_email'
text_version TEXT NOT NULL, -- which wording was shown
granted BOOLEAN NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
Never overwrite a row when a user changes their mind. Insert a new one. The history is the evidence.
3. Plan for data subject requests early
People can ask what you hold about them, ask for corrections, or ask for deletion. If your schema scatters personal data across twenty tables, this becomes painful. Keep one place that knows how to export and erase a user:
export async function eraseUser(userId) {
await db.transaction(async (tx) => {
await tx.anonymize('users', userId);
await tx.delete('consent_records', { user_id: userId });
await tx.delete('sessions', { user_id: userId });
});
await search.removeUser(userId);
await storage.removeUserFiles(userId);
}
Test it. A deletion function nobody has run is not a deletion function.
4. Decide where the system is hosted
Hosting location can matter for regulated clients and for sensitive data. Ask the client, in the first meeting, whether there are residency requirements, then keep the region in config so a move does not mean a rewrite:
const config = {
region: process.env.APP_REGION, // set per environment
storageBucket: process.env.BUCKET_NAME,
allowCrossBorderTransfer: false,
};
if (!config.allowCrossBorderTransfer && isForeignRegion(config.region)) {
throw new Error('Region not allowed for this deployment');
}
Fail loudly at startup. A silent misconfiguration is how data ends up somewhere it should not be.
5. Build Arabic in from day one
Retrofitting Arabic is far more expensive than starting with it. Set lang and dir at the root, use CSS logical properties instead of left and right, and store all copy in locale files:
.card {
margin-inline-start: 16px;
padding-inline: 12px 20px;
text-align: start;
}
Format money and dates with Intl, never by hand, and pick one digit style on purpose (Arabic-Indic or Latin) and keep it consistent in the UI, emails, and invoices. Have a native speaker review labels and error messages. Machine-translated Arabic is easy to spot.
6. Know which national systems you might touch
Depending on the industry, the client may need integrations with systems like these:
• ZATCA for e-invoicing, if the business is VAT registered.
• NPHIES for health insurance exchange, in healthcare software.
• SAMA guidance for financial services.
• Local payment methods such as Mada, STC Pay, and buy now pay later providers, usually through a local gateway.
Wrap each one behind your own interface. Government and gateway APIs change, and you do not want their field names spread across your codebase.
export interface InvoiceSubmitter {
submit(invoice: Invoice): Promise;
}
Always confirm current requirements on the official site of each body before building. They are updated in phases.
7. Treat security as a default, not a phase
For enterprise clients especially, expect questions about encryption and access control. A sensible baseline:
• TLS everywhere, and encryption at rest for personal data
• Role-based access control with least privilege
• An audit log for every read or change of sensitive records
• Secrets in a vault, never in the repo
• Dependency scanning in CI
A small audit helper goes a long way:
export function audit(action, actor, target) {
return db.insert('audit_log', {
action,
actor_id: actor.id,
target,
at: new Date().toISOString(),
});
}
Saudi government and large enterprise clients may also ask how you align with the National Cybersecurity Authority's controls. Ask for the specific list early.
8. Adding AI features without creating a new risk
Many Saudi clients now ask for AI chatbots, document processing, or automation. The same rules apply, with two extras:
• Do not send personal data to a model provider unless you have checked where it is processed and what is retained.
• Test Arabic quality properly. Modern Standard Arabic and Gulf dialects behave differently, and a bot that works in English can fall apart in Arabic.
Log prompts and outputs for review, with the same access controls as any other personal data.
9. Scope in writing
Most failed projects fail on scope, not on code. Write down what is in and out, who approves changes, and what "done" means. Show working software early and often, not only a deck. Weekly demos catch misunderstandings while they are still cheap.
If you would rather hand this whole checklist to a team that does it every week, VirtueNetz is a software development company Saudi Arabia businesses can hire to build custom software, ERP, and AI solutions in Riyadh, Jeddah, and Dammam.
Quick launch checklist
• Data inventory in the repo
• Consent stored as history, not overwritten
• Export and erase tested end to end
• Hosting region in config and enforced
• Arabic and English from the first sprint
• National integrations behind your own interfaces
• Encryption, RBAC, and audit logs on by default
• AI features reviewed for data handling and Arabic quality
• Scope written down and demoed weekly
Final note
None of this is exotic. Do it at the start and a Saudi project runs like any other. Skip it and each item turns into a late, expensive surprise.
Disclosure: I work with the team at VirtueNetz Saudi Arabia, a software development company serving businesses across the Kingdom.
Top comments (0)