Code That Works on the Marketing Site and Inside Customer Accounts

Our platform runs in two very different situations. On customer websites and inside customer admin areas, there is always an organization in context: the account whose site or admin is being used. On our own public marketing pages, there is no customer account at all. Some code runs in both places: layouts, components, caching helpers, search settings and analytics.

Code that assumes a customer is always present will crash on the marketing site. Code that ignores the customer will leak data inside accounts. Here is how we write code that is safe in both worlds.

Ask safely whether a customer is present

Our platform provides a way to ask which account is active. On a marketing page, the answer is "none." Calling for the account's identifier directly when none is active causes an error. So shared code always checks first, in a safe way, whether an account is active, and only then uses its details.

It is a small pattern, written the same way everywhere, and it prevents a whole class of crashes on public pages.

Have a sensible answer for "nobody"

Checking safely is only half the job. The code also needs a clear behavior when no account is active. Depending on the situation, that might mean using the platform's own settings, using a clearly named placeholder in a cache key or simply skipping a customer-specific step.

The worst answer is an empty value that accidentally matches something. A cache key with an empty account slot, for example, could be shared between the marketing site and a customer, which is exactly the kind of leak we avoid. We explain that in why every cache key includes the customer.

Central data is clearly marked

Some records belong to the platform rather than any customer: our own pages, shared templates and supplied blocks. Those records are marked as belonging to no account, and customer-facing code is careful never to modify them. Seeders that work on customer data never touch platform records, and seeders that work on platform records never touch customer data.

Shared records visible to everyone

A few kinds of records are intentionally shared, such as supplied page blocks that every organization can use. Those are marked as system records and are visible across accounts, but they are protected from editing and deletion. Organizations can make their own copies to customize, which belong to their own account and website.

Settings resolve from the right place

Many settings exist at both the platform level and the account level. Shared code reads settings through services that know where to look for each context, rather than reading a raw value directly. We describe the general order in database, environment, config: how our settings resolve.

Brand stays where it belongs

Shared layouts and components must also respect branding. Our platform's own brand appears on our marketing pages and in our admin areas. A customer's public website shows the customer's brand. Shared code checks context before applying a logo, a color or a name, so neither side borrows the other's identity. You can read more in brand colors as tokens.

Background work has no visitor at all

Background jobs and scheduled tasks are a third context: there is no visitor and no web address, and sometimes no account until the job restores one. Shared code that reads the current address, the current visitor or the current account must work there too. We write those helpers so they accept an explicit account and website when one is known, rather than relying on whatever the current request happens to be. You can read more in background jobs that remember their context.

Test both contexts

When shared code changes, we check it in both contexts: a public marketing page with no account and a customer site or admin with an account. A change that works perfectly inside accounts can still break the marketing site, and the reverse is just as possible. Testing only one side is how these bugs reach production.

Frequently asked questions

Why does code crash when no customer account is active?

Code that requests an account's details without first checking whether an account exists will fail on pages that have no account, such as public marketing pages.

How should shared code handle having no account?

Check safely, then use a clear fallback such as platform settings or a named placeholder, never an empty value that could match something else.

Can customers edit shared platform templates?

Supplied templates are protected, but organizations can copy them into their own account and customize the copy.