Other business shapes

The four levels bend to fit very different companies. Here are four, from smallest up. Find yours, copy the shape, move on.

One person, one van

Jamie cleans houses in Bristol. Just Jamie, about 40 regulars, and a phone that rings too much. Jamie wants a booking page.

Jamie's Cleaning              Account
└── Jamie's Booking           Application
    └── Jamie's Cleaning      Franchise  ← named after the company, then ignored
        └── Bristol           Location

Two of these levels exist only because the model requires them. That's fine — they cost one extra request during setup and then vanish from Jamie's life.

What Jamie does: creates it once, hard-codes the Location id in a config file, never touches the platform endpoints again.

What Jamie skips: staff accounts, roles, multiple keys, Franchise grants. All of it. One secret key on the server, one Location, done.

A few sites in one region

Brightside Cleaning — Sarah's company, the running example in these guides. Two crews in Portland, one in Salem, a manager for each, 300 customers.

Brightside Cleaning          Account
└── Brightside Booking       Application
    └── Oregon               Franchise
        ├── Portland         Location
        └── Salem            Location

What changes from Jamie: the Locations are genuinely separate. Portland's customers are not Salem's. Sarah's app has to know which site it's acting on, so the Location id becomes a parameter rather than a constant — usually taken from the staff member's login, or from which site the customer picked.

Why the Franchise now earns its keep: Sarah gives Dev access to Portland only. Her regional manager gets Oregon, which covers both sites and any she opens later.

A brand with owner-operators

Sparkle Group franchises its name. Head office runs the brand; twelve independent operators each run their own patch, some with several sites. Head office sets standard services and prices. Operators can't see each other's customers.

Sparkle Group                        Account
└── Sparkle Operations               Application
    ├── North Region                 Franchise
    │   ├── Hendricks Group          Franchise   ← an owner-operator
    │   │   ├── Leeds                Location
    │   │   └── Bradford             Location
    │   └── Okafor Cleaning          Franchise   ← another operator
    │       └── Newcastle            Location
    └── South Region                 Franchise
        └── Coastal Clean            Franchise
            └── Brighton             Location

This is what the nesting is for. Each owner-operator is a Franchise, so:

• An operator gets access to their own Franchise. They see their sites and no one else's, and when they open a fourth site it's covered automatically.
• A regional manager gets North Region and sees every operator beneath it.
• Head office is unrestricted and sees everything.

Shared price lists: head office defines services once for the Application, and each site opts in. Operators get the standard catalogue without head office touching their customer data.

When an operator sells up: their sites move to the buyer's Franchise. Customers, history and invoices travel with each site.

Software sold to other companies

Tidyflow sells booking software to cleaning companies. Two hundred customers, each running their own business, none of whom should ever see another's data.

Tidyflow                     Account
└── Tidyflow Production      Application
    ├── Brightside Cleaning  Franchise   ← Tidyflow's customer
    │   ├── Portland         Location
    │   └── Salem            Location
    ├── Jamie's Cleaning     Franchise   ← another customer
    │   └── Bristol          Location
    └── …198 more

Each of Tidyflow's customers is a Franchise. Their sites are Locations beneath it.

The important bit: Tidyflow holds the Account, and each customer's data sits in its own database. Isolation isn't something Tidyflow has to be careful about in queries — it's structural.

How onboarding works: when a company signs up with Tidyflow, someone adds a group and a site for them in the dashboard, and issues a key scoped to that group. It's a couple of minutes per customer.

What Tidyflow's code does: everything after that. Its servers hold one key per customer — or one key granted several groups — and pass the right site id per request. Adding a customer is an operations task; serving them is the integration.

Also worth knowing: if a customer outgrows Tidyflow and wants to take their data elsewhere, their site can be transferred to their own account. Both sides have to agree, which makes that a feature you can advertise rather than a risk.

Picking yours

Two rules of thumb:

Make a Franchise wherever you'd want to hand someone a set of keys. If you'd never grant access at some level, that level doesn't need to exist.

Don't over-plan it. Franchises can be created later, and a Location can be moved between them without touching its data. Start with the shape you have now.

Next