Yes. A second workshop, a second shop, several job sites: the site is DATA you describe at generation time, not a software edition to buy. Each record is attached to its own, lists filter, indicators are computed over what you have scoped, and no pricing line depends on the number of sites. Two limits are worth knowing before you start, and they matter: there is no GLOBAL site selector that switches the whole application at once, and accounts carry no per-site restriction — an account that can read, reads everything. This page states what works, which shape to choose for your sites, and what would take development.
The trap is not the price, it is duplication
What the sector's comparisons describe is remarkably consistent: when a small business opens a second outlet without a tool designed for it, it installs a COPY of the existing one. The result is two independent files, two separate billing systems, and no overall view without a manual month-end compilation. On top of that sits a more insidious frustration: many tools advertise “multi-store” without offering real centralised control — you have added tills, you have not gained a network.
So the question is not “does this software offer a multi-site option”, but “how is the site represented in my data”. It is a MODELLING problem, and that is exactly where an application described then generated behaves differently from an off-the-shelf product: there is no higher edition to unlock, there is a description to get right once.
The site is data, not an edition of the software
In practice you describe it like everything else: “I have two workshops, North and South; every job, every part in stock and every customer belongs to one of them, and I want to see my figures per workshop.” The generator then produces the matching structure — the entity or the list of values, the attachment of each record, the screens that filter. Nothing is guessed: what you do not write does not exist, and what you do write is produced deterministically.
One point deserves to be stated plainly because it is unusual: no line of the pricing grid depends on the number of sites. Plans differ by the number of active applications and by generation volume, not by how many premises, workshops or job sites your application tracks. A third site is not a tier to cross, it is one more value in a list.
Which shape to choose for your sites
Two shapes exist and they do not give the same thing, so it is worth choosing knowingly. If your sites are few and stable — two workshops, three shops — declare them as a LIST OF VALUES. That is the shape that gives the most: the filter panel then carries a site selector next to the search, the chosen filter survives in the page address — so a link to “overdue jobs at the South workshop” can be sent to a colleague as is — and the views that group by status can group by site too.
If your sites are proper records — an address, a manager, opening hours, a contact — then they are RECORDS in their own right, linked to your other data. You gain the site's own record sheet, you lose the immediate selector: the filter panel only adds a dedicated criterion for lists of values, other fields being folded into the full-text search, which already covers them. And in both cases, a dashboard indicator can be scoped to one site, with a click landing on the matching list, already filtered.
The two limits to know before you start
The first: there is no GLOBAL site selector. Filtering lives in each list; there is no switch at the top of the screen putting the whole application into “South workshop mode” for the session. For a small outfit that wants precisely the overall view, this is no hindrance — it is the opposite of the problem described above. For someone who spends the day on a single site and never wants to see the others, it is a real inconvenience, and better known in advance.
The second is more serious: accounts carry no per-site restriction. An application requiring a login ships real user management, each with their own credentials, read-only or with edit rights — but that right applies to the application, not to a perimeter. An account that can read, reads everything. If confidentiality between sites is a requirement, there are two paths: have that partitioning added to the code, which is yours and exports, or generate one application per site — accepting that you then land back on exactly the initial problem, the missing overall view. Saying so up front beats discovering it afterwards.