Laravel development for Brisbane franchise and multi-site groups

A Brisbane franchise system is one application pretending to be forty businesses, and the entire risk profile comes from that pretence.

The data is in one place. Forty franchisees, each a separate business with separate accounts and sometimes a competitive relationship with the one in the next suburb, all querying the same tables. One missing condition on one query shows one of them another's revenue, and that is not a bug report - it is a phone call to head office from somebody's lawyer.

Brisbane tenant isolation has to be structural

A convention that queries should filter by tenant will be broken, because conventions are broken by new developers, by console commands written in a hurry and by code paths nobody remembered.

So the scoping is applied at the model rather than at the call site. The tenant is resolved once for a request and every tenant-owned model carries a global scope that uses it. Nothing passes a tenant identifier around as an argument, because an argument can be omitted.

The half that actually leaks is outside the request lifecycle. A queued job has no request to resolve a tenant from. A scheduled task runs for everybody. An artisan command run by an administrator sees everything by default. Each of those has to establish its tenant explicitly before touching data, and a job that does not carry its tenant is a bug regardless of whether it has caused one yet. Multi-tenant work is the longer treatment.

One Laravel database, scoped properly

The instinct when isolation feels risky is a database per tenant, and for a franchise group that is usually the wrong trade.

It makes isolation trivial and makes everything else worse. Forty databases means forty migrations to run and verify, a connection strategy that has to switch per request, and any question about the whole group becomes an export-and-combine job rather than a query. Operationally it is a permanent tax.

A single schema with a tenant column and enforced scoping requires more care in the first week and far less for the following five years. It is also the version in which head office can ask a question about the group and get an answer the same day.

Reporting across Brisbane tenants needs a door, not a hole

Head office legitimately needs figures across every location, and the way that requirement gets satisfied determines whether the isolation survives.

The wrong resolution is to make scoping optional so that reports can work. Once the scope can be bypassed anywhere, it is effectively bypassed everywhere, because the next person to write a query will copy whichever example they found first.

The right one is a small number of named places that query without the scope, deliberately and visibly, with their use recorded. Everything else cannot. That is a door with a lock on it rather than a missing wall, and the difference is whether anybody can tell afterwards who looked at what - which is the same argument as authorisation belonging at the data.

Brisbane franchisees do not all want the same configuration

Forty sites on one system will not accept one set of rules, and the group does not want forty unrelated ones either.

So configuration inherits. The group sets a default, a region may override it, a site may override that, and the value in force at a site is resolved down the chain rather than copied into it. Copying is what breaks this - once a default has been written into forty rows, changing the group policy means forty updates and the two that were edited locally get silently reverted or silently missed.

Which settings a site may change at all is itself policy and belongs in the data. Trading hours, yes. Tax treatment, no. The discount ceiling, within a range the group sets. Expressing that as a per-setting rule means head office can loosen or tighten it without a release, and a franchisee cannot discover an override that was never meant to be theirs.

Changes to configuration need the same audit as changes to money, for the unglamorous reason that most disputes between a group and a site turn out to be about a setting. Who changed the commission basis, when, and what was it before. That is a row, and having it ends the argument in a minute rather than a week.

Onboarding a new Brisbane site should not be a deployment

Opening a site is a business event that happens on a Tuesday and should not require an engineer.

That means provisioning is an operation the application performs on itself - create the tenant, seed its reference data from the group template, attach its domain or subdomain, create its first administrator, and leave it in a state where somebody can log in and start configuring. Every one of those steps written as code that runs in order, idempotently, rather than as a checklist somebody follows.

The test for whether it is real is whether a tenant can be created and destroyed in an automated test. If it can, onboarding works and so does every tenant-scoped feature, because the test suite is exercising the provisioning path constantly. If it cannot, the first site opened in six months will surface three things that were only ever done by hand on the original tenants.

Closing a site is the half nobody specifies and it needs an answer before the first one closes. The data cannot simply be deleted, because the group's historical reporting depends on it and there are retention obligations on transaction records. A closed tenant is a state - no logins, no new transactions, excluded from operational screens, retained in reporting - and defining it while nothing depends on the answer is considerably easier than defining it during a dispute.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - the privacy and breach regime, hosting, invoicing in Australian dollars - is on the Australia market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars by bank transfer, with no Turkish VAT under the export-of-services exemption.