Does classification mean we cannot use a cloud provider?

No. It means the answer depends on what the data is, and that you have to be able to say what it is. Much of a typical application is unremarkable and can sit anywhere; a narrower set is sensitive and its treatment follows from that. The trouble comes from applications that cannot tell you which tables are which.

Who decides how data is classified?

Your organisation does, against the regulator's categories, usually with legal advice. Our part is making the classification real in the system - so it is recorded per table and per field, enforced by where things are stored, and visible to whoever has to answer for it.

Can this be added to an existing application?

It can, and it is an audit before it is a change. Working out what a mature application stores and where it flows is most of the effort, because the answer is rarely documented and is frequently surprising to the team that built it.

Is there VAT to handle?

Not currently. It has been discussed for years across the Gulf and Kuwait has not introduced one, so the sensible position is to carry the model at a zero rate rather than to build as though tax can never exist. Adding it later to a system without it is a far larger job than carrying a column that reads zero.

Laravel in Kuwait

Laravel development services for Kuwaiti businesses

Kuwait regulates cloud use by classifying the data first. That turns "where does this run" into a question you answer per table rather than per application.

Updated September 22, 2026

Most countries regulate where data may go. Kuwait's framework starts a step earlier, by requiring that data be classified, and lets the classification decide what may be done with it.

That is a different shape of obligation, and it changes a question most projects answer once - "which region do we deploy to" - into a question that has to be answered per kind of data.

Classification is a schema property

The regulatory framework governing cloud use here sets out categories of data with different handling requirements, up to and including restrictions on what may leave the country. Which category applies is a matter for your organisation and its advisers; what follows from it is engineering.

The applications that handle this well have three things, and they are cheap to build and expensive to reconstruct:

A classification recorded against the data itself. Not a spreadsheet maintained separately from the system - a documented statement, per table and where necessary per column, of what it holds and which category it falls in. Kept next to the migrations, so a new table without one is visible in review.

A storage decision that follows the classification rather than the habit. If one category has to remain in-country, that is a connection, a disk and a backup target - not a promise. Applications that separate this cleanly usually split the sensitive store from the rest early, because retrofitting the split means moving data while the system runs.

A flow you can describe. Where each category travels: error tracking, logs, email, analytics, backups. This is the part that catches people. An application can store a sensitive field correctly and then put it in an exception message that goes to a third-party service in another country, and nobody notices until somebody reads the flow diagram.

The failure mode is not the database

It is everything around it. On a Laravel build the recurring offenders are predictable:

Exception reports that serialise a model, including the fields you were careful about. Query logs that capture bindings. Queue payloads written to a store somewhere else. Backups that go to whichever bucket was convenient. Emails rendered with customer data and relayed through an external provider.

Each is a legitimate engineering tool and each is a copy of your data somewhere you did not think about. The classification work is worth almost nothing if it stops at the primary database, and doing it properly means listing the copies.

Build for a tax that does not exist yet

There is no value added tax in Kuwait today and there has been persistent discussion of one across the region. The sensible engineering position is the same as in any country in that situation: carry the model at a zero rate.

A tax column on the line item, a total on the invoice that currently reads zero, a registration field that is currently empty. It costs a migration now, and it is the difference between a configuration change and a quarter of reconciliation work if a tax arrives on somebody else's timetable.

Arabic, and the identifiers

Arabic reaches the database rather than stopping at the templates - collation decides sorting, and normalisation at write time is what makes search work for names typed with different letter forms. It is a migration once there is data.

Civil identification numbers are structured and checkable. Validating at entry rather than storing free text prevents a class of problems that otherwise surfaces at the point where you have to submit something to somebody.

Working with us

We work remotely from Ankara, in English. Kuwait is an hour ahead for most of the year, and its Sunday-to-Thursday working week overlaps ours by four days.

The engineering is our usual application development and database work. What Kuwait adds is that the hosting decision follows the classification rather than preceding it - and that the classification has to cover the copies, not just the database.

Classifying data per table means deciding, per table, what deletion means. A soft delete is not a deletion in the sense a regulator means, and that is easier to settle while the classification is being written than during the audit that reads it.

Invoicing and payment. In US dollars, by bank transfer to an IBAN. The invoice is issued in Türkiye by Codefacture Yazılım A.Ş. and carries no Turkish VAT, because exported services are exempt. Where a contract needs to state where the work is performed, we put it in writing, since the classification rules above make that a question somebody eventually asks.