Many Projects, One Team: Access and Billing When Localization Outgrows One App

Most localization setups are born simple: one app, one project, three people who all know each other. Nothing in this post applies to that, and if that is where you are, the rest is premature.

It changes with the second app. Then a mobile client, a marketing site, a customer portal, an internal admin tool. Every one of them is a legitimate project of its own: own release cadence, own languages, own plan. And at some point between the second and the fifth, the work stops being about translation and starts being about administration.

What actually breaks when the second project appears

The same invitations, again and again. Eight colleagues, five projects, forty invitations, and every new hire repeats the ritual. It is tedious rather than dangerous, which is precisely why nobody fixes it until something else goes wrong.

Offboarding becomes a memory game. Someone leaves the company, or moves to a team that has nothing to do with the portal anymore. Now the question is which projects they were ever added to. If the answer lives only in each project's user list, revoking access means remembering every project that exists, and the cost of forgetting one is a person who still edits your production copy months later. This is the failure mode that turns an administrative annoyance into a security finding.

The invoice fragments. Five projects, five subscriptions, five renewal dates, five receipts to reconcile. Finance asks why one company pays a localization vendor five times, and the honest answer is that the tool had no concept of a company.

Externals get more access than intended. The freelance translator needs Italian on the marketing site. The path of least resistance grants them a role that reaches further than that, because narrowing it per project is work. Multiply by every contractor and agency contact over a couple of years.

Nobody can answer "who has access to what?" Not because the data is missing, but because it is spread across N project user lists with no place that aggregates it. The first time somebody asks that question seriously, it is usually an auditor, a customer security questionnaire, or an incident.

Why the usual workarounds do not hold

One big project with namespaces. Tempting, because it collapses the administration problem instantly. It also collapses everything you separated the apps for: a namespace is a slice of content inside one project, so it shares that project's versions, its publishing, its plan and its access rules. Two products that ship on different days cannot share one release cadence, and "the intern can edit the marketing copy but not the checkout flow" is not expressible in a structure where both are namespaces of the same thing.

A shared login. It solves the invitation problem by destroying the audit trail, makes 2-factor authentication meaningless, and turns every offboarding into a password rotation. It shows up more often than anyone admits.

A spreadsheet of who has what. Correct on the day it is written. The moment access is granted somewhere without the spreadsheet being updated, it is worse than nothing, because it is now a document that confidently states something false.

What the structure should look like

The pattern that holds is an account layer that sits above the projects and owns the two things that are facts about the company rather than about an app: the people and the bill. Four properties make it work.

One roster, inherited into every project. You invite a colleague once, at the account, with the role they should have across the company. They appear in every project of that account with that role. Grant in one place, revoke in one place. This is what makes offboarding a single action instead of a search.

Two kinds of role, and only one of them is inherited blindly. Roles that run the account (administration and billing) belong to the account and reach everywhere by definition. The working roles (manage, publish, translate) inherit too, but a project has to be able to say "not this person here": narrow them to one language on this project, or block them from it entirely. Without that override, an inherited roster is too blunt to use, and teams go back to per-project invitations.

Externals stay on the project. The roster is for your own team. A freelance translator or an agency contact gets a permission on exactly the project they work on, and never sees that the rest of the account exists. This one rule is what keeps the inheritance safe: everything on the roster is deliberately company-wide, so anything that must not be company-wide is not on the roster.

One account, one subscription, one invoice. Every project bills inside its account. When a department genuinely needs its own invoice, its own payment method or its own set of people, that department is a second account, not a special case inside the first. Trying to express two invoices inside one account is where these models usually turn into something nobody can reason about.

On top of that, a handful of things only make sense at the account level: single sign-on (an identity provider is a fact about the company, not about an app), enforced 2-factor authentication, and an audit log of who was granted and revoked what. Configuring those per project is both busywork and a way to end up with five different security postures in one company.

How this works in Locize

This is the shape of organizations in Locize, and the reason we built them.

Your organization is the account layer. You get one automatically with your first project, named after your company, and you can rename it any time. Everything above is how it behaves:

• The roster lives on the organization page. Members are invited once and inherit into every project, with a "via organization" badge on each project's user list so you can always tell inherited access from a direct one. A direct project permission wins for the working roles, so you can narrow or block someone on a single project, and "inherit" hands them back to the organization's rule. Details in user management.
• Admin and accountant exist only on the organization. Project permissions top out at manager. That is what makes the offboarding story true: there is no way to accumulate company-wide power project by project.
• Billing is the organization's. The first project that subscribes creates the subscription, and every further project joins it: one invoice, while each project keeps its own plan and limits. Sharing an invoice is included from the Growth plan upward.
• A separate invoice is a separate organization. You can create one directly from the add-project form, and move an existing project across with a one-time handover code: the receiving admin sees which project arrives and from whom before confirming. Tenants and branches follow their parent project automatically (multi-tenant).
• SSO is charged once per subscription, no matter how many projects use it. Enforced 2-factor authentication is set for the whole organization, and a project can strengthen it but never weaken it. Organization admins can download the audit log of member and invitation changes on plans that include it.

If you were already using collective billing, none of this asked anything of you: your billing group became your organization, its admins became organization admins, everyone kept the projects they had, and the invoice stayed the same or got slightly cheaper, since SSO is now charged once per subscription instead of once per project.

When you do not need any of this

One app, one or two people, no external translators, no compliance questions: leave it alone. A single project with a couple of direct permissions is the correct structure, and adding an account layer on top of it buys nothing. The signals that it is time are concrete and you will recognize them: the third project, the first person who has to be removed from several projects at once, the first invoice question from finance, the first security questionnaire that asks how access is granted and revoked, or the first contractor you had to give more access than you wanted.

The point of the account layer is not that it manages your translations. It is that it stops the administration around them from growing with every product you ship.

If several of those signals sound familiar, the fastest way to see the shape is to look at your own setup: the organization page lists every project, who reaches it and what it costs this period. Start free with Locize, or read the organizations documentation first if you would rather see the model before the product.