Laravel development services in Saudi Arabia

Three things change for a Saudi build, and all three are architecture rather than presentation.

E-invoicing is an integration with a queue behind it

ZATCA's Fatoora programme makes an invoice a signed, structured document submitted to the authority - cleared before issue for business-to-business invoices, reported after issue for business-to-consumer. In application terms that is a cryptographic signing step, a UUID and hash chain across your invoice sequence, a QR code, and an API call with a response you have to store.

The framework part is unremarkable. What decides whether the integration is sound is everything around it:

• The submission is a queued job, and that job must be idempotent. A duplicate submission is a regulatory artefact, not a retry. The idempotency key belongs in the invoice record, generated once.
• A failure needs somewhere to go that a human reads. An invoice that failed clearance and sat in failed_jobs is an invoice that was never legally issued, and the business will find out from the customer.
• The chain cannot have gaps. Each invoice references the previous hash, so a record deleted or reissued out of order breaks the sequence rather than producing one bad row.
• The archive is a system requirement. Signed documents retained for years, readable, with the signature still verifiable.

This is the part of a Saudi build that most resembles payments work, and it should be scoped like payments work rather than like reporting.

Residency decides hosting, before anything else

Data residency rules apply to an expanding set of categories, and public-sector engagements generally impose them outright. That makes the hosting decision a constraint on the architecture rather than an operational detail: which region, which provider, where backups live, and where support staff access the system from.

It is cheap to design for and expensive to move later, so it belongs in the first week. A team that picks a provider for convenience and asks the residency question before launch has usually bought itself a migration.

Arabic reaches the database, not just the theme

This is where most of the applications we audit have gone wrong, because RTL is treated as a stylesheet problem.

It starts in the schema. Collation that sorts and compares Arabic correctly. Columns that can hold both an Arabic and a Latin form of a name, because invoices, contracts and government submissions frequently require both. Search that handles Arabic normalisation - a query that fails because of a diacritic or an alternate letter form is a search box users stop trusting.

Then the layout, which is genuinely straightforward if it is done from the start: logical properties rather than left and right, so the interface mirrors without a second stylesheet, with code, numbers and Latin-script brand names pinned explicitly. Retrofitted afterwards, it is a week of finding the twelve places that did not mirror.

Hijri dates, where they belong

Some documents and interfaces need the Hijri calendar. Store in UTC and convert for display - the same rule as every other calendar concern - and decide once, in writing, which documents are dual-dated. The failure we see is a Hijri date stored as a string, which makes every subsequent comparison and sort wrong in a way nobody notices for months.

What we do here

The same application development and API work we do anywhere, with the regulated integration treated as queue engineering - because that is what it is.

Engagements run in English, remotely from Ankara, which is one time zone from Riyadh and makes a working day genuinely shared.

The ZATCA integration is a queue problem as much as an XML one. Submissions that must not be sent twice, retries that have to be safe, a clearance response that arrives later than the request. Every job will run twice eventually, and designing for that is the engineering.

Invoicing and payment. In US dollars, by bank transfer to an IBAN. Codefacture Yazılım A.Ş. invoices from Türkiye and the invoice carries no Turkish VAT under the export-of-services exemption. It does not pass through ZATCA. Clearance applies to invoices issued inside the Kingdom, not to a supplier invoice arriving from abroad.