Your Brand, Your Modules, Your Name On It

The question this section answers: what has to be true before a buyer will put their own name on software somebody else built. The fastest way to make a client portal feel like rented software is to leave the vendor's name on it. The buyer's customer signs in and sees a product they have never heard of, wearing colors that are not the buyer's, with a support link that goes somewhere else. Every one of those details tells the customer that the business they are dealing with is a tenant. Most white-label offerings address this with a logo slot and an accent color, which is a theme over a shared system, and a theme is exactly as thin as it sounds: the first unbranded string, the first default illustration, the first empty module the buyer does not use and cannot remove, and the illusion is over. So a Canopy install is not a theme. It is the whole system, carrying the buyer's name, mark and colors, with the parts they do not need switched off. One codebase runs deployments that look and behave like genuinely different products: their own product name throughout, their own logo, their own accent palette through the entire interface rather than on a header bar, their own assistant with its own name and its own opening line, their own sign-in doors, and their own module set. Three installs of the same code can sit side by side and read as three companies' software, because at the level the user is operating, they are. The module set is the part buyers underestimate until they see it. A business with no mailbox in their portal does not get an empty inbox with a friendly message about connecting one. A business that will never buy a website scan does not get a tab for it sitting permanently at zero, inviting them to wonder what they are missing and whether they are on the wrong plan. Every visible surface that does not apply to a buyer is not dimmed or gated behind an upsell. It is not there. This matters more than the logo, because an empty feature is a constant advertisement that the software was built for somebody else and the buyer is using a subset of it. The buyer's staff should open the product and see a tool that was made for their business, because operationally that is what it is. I considered the conventional approach, which is one deployment serving every customer with branding resolved per request from the hostname. It is substantially cheaper to operate and it is what almost everything in this category does. I rejected it for the same reason the architecture section gives, and the branding question makes the reasoning unusually concrete. In a shared deployment, the buyer's brand is a row in a configuration table that my code reads on every request. The buyer is not the owner of their own product identity; they are a lookup. If the lookup is wrong, or the cache is warm from another tenant, or a query forgets the tenant filter for one release, the buyer's customer sees somebody else's company name on the buyer's own portal. That is not a theoretical failure. It is the ordinary failure of multi-tenant systems, and its blast radius here lands directly on the buyer's relationship with their customer. The per-install answer removes the failure rather than defending against it. One install is one database, one sign-in and one deployment, all the buyer's, with no shared infrastructure between them and anybody else. There is no central account of mine the data passes through and no tenant column anywhere that could be queried wrong. That is why the ownership claim is honest rather than a slogan: there is literally nothing to leak across customers, because there are no other customers inside the install. The branding is not resolved at request time from a table. It is what the buyer's install is. What this costs me is real and I chose it knowingly. A branding change is a deployment rather than a database update. A new module set is configuration applied per install rather than a flag flipped centrally. Provisioning is hours rather than seconds. I built tooling so the operational tax is bounded, but the tax exists, it compounds with every install, and it is paid by the studio rather than by the buyer. That is the correct direction for it to fall, because the buyer is the one paying for the outcome. Authority inside an install is four tiers, assigned per person and revocable at any moment, and a disabled account cannot sign in at all. The tiers run from full control, which includes deciding who else gets in, down to a read-only tier that can browse everywhere and will be refused by any control that changes something. The important property is not the number of tiers. It is that the buyer's own primary administrator assigns and revokes all of them without me being involved, and that every assignment is itself recorded. Access the buyer cannot change on their own is access they do not really control. And the way out is a control on the settings page rather than a support ticket. Every entity exports to CSV and the whole database exports at once. This is the clause that makes the rest of the section testable rather than rhetorical. Anyone can claim a buyer owns their install. The claim only means something if the buyer can act on it on a Tuesday afternoon without asking permission, without a notice period, and without a conversation about why they want it. The test ownership has to pass is that the buyer can fire me and keep operating tomorrow morning, and an export button they can press today is the part of that test they can run while they are still happy with the arrangement. The honest exclusion: the white-label layer is real and running across live deployments, but which client runs which edition is theirs to say and not mine. The three installs shown on the tour are invented businesses built to demonstrate the layer, not a customer list. A vendor who proves their discretion by naming the customers they were discreet about has proved the opposite. The operational consequence the buyer feels is that the software stops being something they subscribe to and starts being something they have. Their staff open a product with the company's name on it, containing the parts of the business they actually run and none of the parts they do not. Their customers sign in to the company's own domain and never encounter my name anywhere. And the ownership behind that presentation is not a promise in a contract, it is the shape of the deployment: their database, their sign-in, their domain, their export button, and no shared infrastructure between them and anybody else in the world.