Several businesses, one login, zero posts on the wrong account

If you run more than one brand, it has already happened or it is going to: the clinic post went out on the bakery account. And when it happens, the explanation is always the same — “I had two tabs open”.

The explanation is right. The conclusion that it was carelessness is what is wrong.

The bug is not yours, it is the software

Multi-brand tools tend to store the selected business in one of two places: the server session or browser local storage. Both are global to the tab — worse, the first is global to the entire login.

What that produces in practice:

• You open two tabs, switch business in one, go back to the other. The other one also switched business, but still shows the old screen.
• You hit refresh on a page and land in another business.
• You send a link to a colleague and it opens on their business, not yours.
• The back button takes you to the right screen of the wrong business.

None of those is an error by the person clicking. They are predictable consequences of storing a piece of context somewhere that is not the address.

The business lives in the URL

The fix is structural and fits in one line: the business identifier is part of the page path.

In EverFeed, a creatives screen has an address like /u/aurora-bakery/creatives. The business is not in a hidden variable — it is in the address, visible in the browser bar.

That solves the four problems at once, and solves them by construction:

• Refresh reloads the same business, because the business is in the address that was reloaded.
• Two tabs stay on different businesses without interference, because each has its own address.
• A pasted link opens where it should: whoever receives it sees the same business you saw.
• Back goes back to the previous screen and the previous business.

It is an architecture decision that looks like a detail and eliminates an entire category of error. It is not “be careful when switching business” written in a warning — it is the error ceasing to be possible.

What needs separating, and what does not

Separating everything is as bad as separating nothing: it multiplies the work per brand. The split that works:

Separate per business: the entire brand kit (personas, voice, offers, colours, fonts, compliance), the media library, the connected channels, the calendar and the pieces. Everything that is identity or content.

Shared across businesses: AI providers, the prompt library, integrations and API tokens. Everything that is infrastructure.

That split has a big practical consequence: you configure the AI provider once and it serves all five brands. Configuring the same key five times would be pure work with no benefit.

And there is a useful exception in the middle: prompts can be global or exclusive to one business. A caption prompt serves all of them; if one brand has its own way of writing a hook, it gets its own prompt, which overrides the global one there only.

A colour per business, on the chip

The calendar has a mode that shows every business together, and in it each piece appears in the identifying colour of the business it belongs to.

That sounds cosmetic. It is not: it is what lets you glance at a week and see that the bakery has five posts and the clinic has one, without clicking anything. Unbalanced distribution between brands is the most common problem for anyone running several, and it is invisible when you look at one calendar at a time.

The same applies to the home panel: with the scope set to “all businesses”, the same counters — to review, scheduled, published, running — appear broken down per business. It is the Monday morning report for anyone managing several accounts.

The price should not multiply

There is a common practice in this category: charging per brand, or per “workspace”. It turns every new client into a cost decision, and it is especially bad for anyone with one large brand and four small ones.

In EverFeed the plan is per account, not per business. Eight dollars to publish, eighteen to generate, and the number of businesses is up to you. The system variable cost is in the generation — and generation, on the bring-your-own-key path, you pay directly to the vendor.

Three habits that prevent the rest of the errors

1. Check the address bar, not the header. When the business is in the URL, it is the source of truth. A header can be stale; the address cannot.

2. One tab per business, and watch the favicon. Because each tab keeps its own business, you can work in parallel without risk. That is the difference between a feature and a trap.

3. Review in batches per business, not per day. Switching brands on every piece is what produces tone errors — the clinic voice leaking into the bakery. Review one brand five pieces at a time, then move to the next. Batch review is also faster.

One extra detail for agencies

Anyone serving clients has a need that people running their own brands do not: showing results without giving away panel access.

Two things help. The first is metrics with history, which answers “what happened this month” without you recompiling anything. The second is API tokens: you can pull the numbers into a spreadsheet or into the report the client already receives, instead of taking screenshots.

It is the same endpoint the panel uses. There is no second-class API — whatever the panel can do, a script of yours can do.