Your operation in a single database

Each client gets their own database

Each client’s data lives in its own database, inside its own container, on an internal network that never touches the internet. It is not folder-level separation inside a shared system, nor a “client_id” column someone can forget to filter on.

• The database is not on the network that receives outside traffic. The tunnel serving the website cannot see it, not even by name.
• The day you want to take your database, it is handed over whole with nothing to filter out, because there is no one else’s data inside it.
• What we record about our own operation lives in a different system and is not delivered with any project.

The database refuses to store impossible things

The usual approach validates in the application. That works until a second process writes — an import, a bot, someone with direct access — and in walks data the application would never have accepted. Here the rules live in the database, so they hold no matter who is writing.

• An appointment for a professional who does not exist cannot be stored: the name is a foreign key, not free text.
• A unique index over professional, date and slot makes double-booking impossible — and makes reloading the calendar duplicate exactly nothing.
• A form lead does not get in without a name, an email and the authorisation with its exact timestamp. That rule belongs to the database, not to a checkbox in the browser.
• Amounts are declared with the type that preserves precision, not as a floating-point number that rounds behind everyone’s back.

Every process connects with minimum permissions

Permissions are granted per column, not per table. That sounds excessive until you consider what an automated assistant could do the day someone sends it something strange.

• The assistant answering WhatsApp can record an appointment and cannot read back a single conversation it wrote itself.
• It can write to four columns of a table and to none of the others. It is not that the application stops it: the database denies it.
• Permissions are reapplied on every start, because rebuilding a view silently drops them — precisely the failure nobody notices until something stops working.

The schema is a file, not a series of manual changes

The full structure of the database lives in a version-controlled file and is applied whole on every start. It can be read, reviewed and compared against what it was a month ago. Nobody has to “remember” what changed.

• Applying it twice changes nothing: it is written to be repeatable.
• Standing up an identical clean copy is one command, not an afternoon.
• Queries are never assembled by pasting text together. Values travel as parameters, which is what keeps a value containing a quote mark from turning into an instruction.

And there are backups, proven by restoring them

A backup nobody has ever restored is an assumption. Ours was restored for real: the local copy deleted, the offsite one pulled down, decrypted and loaded into a clean, isolated database to confirm it was complete.

• Daily automatic backup, encrypted before it leaves the server.
• Seven copies on the server and thirty off it, with a different provider.
• If a backup fails it alerts; and if it stops running at all, it alerts too — which is the failure that actually goes unnoticed.

It can be shown working

None of the above is a brochure promise: each point maps to a concrete decision and can be seen running. If you are deciding who to hand your company’s data to, ask to see this — from us or from anyone else.