A workspace is the thing you pay for, with its plan and its limits. A client is the company an agency works for, with its tax details and its portal access. A brand is what you publish for, and the connected accounts, the link page and the monthly report mode all hang off it. The brand is the unit of the product.
Three words that are not synonyms
Almost every tool in this category has one word for all of this and stretches it. Sometimes it is called an account, sometimes a profile, sometimes a project, and it stands at once for the thing being paid for, the person paying, and the thing being published. It works while those three coincide, which is exactly the case of one person with one Instagram account, and it stops working the moment a third party walks in.
Here they are three different things, with three different tables behind them.
| Workspace | Client | Brand | |
|---|---|---|---|
| What it is | The tenant: the thing you pay for | The company you work for | The thing you publish for |
| Who has one | All three workspace kinds | Agency workspaces only | All three workspace kinds |
| What it owns | The plan, the limits and the team | Tax details, documents and portal access | Connected accounts, link page and report mode |
| How many | One per subscription | As many as you run, in an agency | As many as the connected accounts you contracted |
The practical difference between a client and a brand shows up in one very common case: a restaurant hires you and it has two sites with two separate Instagram accounts. That is one client and two brands. One invoice, two calendars, two inboxes, two reports. With a single word for everything, that case forces you to choose between billing twice and mixing two calendars into one. The full breakdown of the three concepts is in workspaces, brands and clients.
The brand is the unit, not the connected account
The obvious alternative was to make the connected account the unit: one Instagram, one calendar. Plenty of tools do exactly that and it is easier to build, because you do not have to invent a concept the platforms themselves do not have.
We did not, because it breaks the moment a brand publishes on more than one network, which is always. If the account is the unit, the same carousel gets scheduled three times, one brand's analytics live in three places, and whoever reviews has to remember to look in three. With the brand on top, one piece goes out to every network that brand has connected, the monthly report adds up what that brand did, and the inbox gathers what arrives from all of its accounts into one thread list.
Three more things hang off the brand that nobody expects to be per brand until they need it that way: its link page, with its own colours and its own stats; the colour it wears in the calendar, which is what makes a week with six brands on it readable at all; and the monthly report mode, which can be off, sent on its own on the last working day, or generated as a draft for somebody to review first. That last setting is per brand precisely because a client with two sites almost never wants the same treatment for both.
A creator workspace has no clients
This is the decision that cost the most code to hold. A creator workspace has no clients at all: its brands hang directly off the workspace and the word client never appears on any screen. A company workspace works the same way, it has a team but no third parties contracting the work.
The comfortable option would have been to create an invisible client for those workspaces and reuse the whole agency product underneath. That is the kind of shortcut you pay for over years: every screen ends up showing a concept that user does not have, every string says client to somebody who has none, and the day you want to change the vocabulary you find it written in two hundred places.
What we did instead was admit the absence in the model itself: a brand may have no client, and that absence is the workspace kind. The vocabulary moves with it, where an agency reads clients a creator reads brands, and there is a check that runs over the code and fails if a screen a client-less workspace can open mentions the word. It is not a style convention, it is a test that breaks the build.
What changes in permissions, reports and billing
Once the brand is the unit, most of the rest follows, and it is worth knowing in which direction.
- Permissions are split by module, not by brand. A role is a name and a list of permissions with two levels, read and write, and what somebody can do is the intersection of what the workspace has contracted and what their role grants. What does not exist today is a role that opens two brands and leaves the other six out, and that is the least comfortable consequence of putting the brand below the workspace. How a role is built is in roles and permissions.
- The monthly report belongs to one brand, because those are one brand's numbers. The analytics themselves are available to everyone; the PDF report that sends itself is an agency workspace feature.
- The invoice belongs to the client, with its legal name, its tax number, its VAT, the Spanish VAT, and its IRPF withholding where one applies. That is why it lives at the client level and not at the brand level: the restaurant's two brands go on one document.
- The limits belong to the whole workspace. Members, storage, social accounts, ad accounts and automation contacts are all counted at workspace level, never per seat.
Everything in this article happens in one place in GoFeed.
Try it freeWhat this decision cost
Three costs, and none of them is theoretical.
The first is that brands are not sold by the number. Since every brand needs at least one connected account, what limits how many brands fit is how many connected accounts you have contracted: with ten accounts and none connected there is room for ten brands, and with nine connected on a single brand there is room for one more. It is more honest and harder to explain than printing a brand count on every plan, and it obliges us to explain it every time. What gets counted and how is in seats and quotas, and the current tiers are on the pricing page.
The second is that the model arrived after the product. Brands did not exist from the start: at first the client was also the thing you published for, and separating the two was a migration over live data, with one decision that still follows us around. Every brand created in that migration kept the identifier of the client it came from, so that no saved address would stop working. The side effect was that for months a bug confusing a client identifier with a brand identifier worked perfectly on the old accounts and failed only on the new ones. Three bugs of that shape took a long time to find, and all three were the same bug.
The third is that vocabulary has to be carried all the way down. When we renamed the tenant, from agency to workspace, the change had to reach the database tables so that the product would not end up speaking two languages, one on screen and another underneath. How that is done without taking the service down is told in renaming a live product.
None of this is visible from outside, which is why it is worth saying before somebody finds out while setting their workspace up: data model decisions do not show in a screenshot, they show three months later, on the day you need to separate two things a tool stored together.
How the kind is chosen, and how it changes
The workspace kind is chosen when the account is created, and three questions decide it: are there third parties who hire you, is anybody else working with you, and how many brands do you publish for. If there are third parties, it is an agency. If there are none but there is a team, it is a company. If neither, it is a creator.
It can be changed later, and what changes with it is which modules that workspace can hold. What does not change is the model underneath: brands stay brands, connected accounts stay hanging off them, and the history stays where it was. A creator who starts taking on clients migrates nothing, they gain a level above their brands that they did not need before.