The brand guidelines PDF has a specific moment of death, and it is the handover. A designer on r/graphic_design asked it plainly: "this is my first time I'm creating a brand guidelines document for my client. I don't know how to handover it to the client." Whatever the answer was, the file went into a Drive folder, and six months later the client's contact form was one purple, their link-in-bio was another, and the chat widget on the site still ran the vendor's default blue.
I run SharpHaw, a small agency in Lisbon, and I'm the engineer behind SharpOS, the workspace we run every client engagement in. Brand Kit is the row on our replacement ledger that stands in for the PDF. This is what it does, how it's built, and where it is deliberately smaller than the tools designers already use.
TL;DR: the PDF describes the brand; the kit is what the client's forms, link page and support widget read at runtime. We kept it small on purpose.
What the PDF is for, and where it breaks
A brand guide is an argument. It says why the mark looks the way it does, what the photography should feel like, which CMYK values stand in for a hex that print can't reproduce. None of that belongs in a database, and I'm not proposing to put it there.
The problem is narrower. Nothing executes a PDF. A veteran on r/branding put it better than I can: "If your identity isn't embedded in the tools your team actually uses, it will drift. Within six months, your social media will look different from your site." For an agency the drift is worse, because the touchpoints that go wrong are the ones we ship. A form we built, a link page we built, a chat widget we embedded. If those don't read the brand from somewhere, we are the drift.
What Brand Kit does instead
Every organisation in SharpOS gets one Brand Kit at the Brand page of the hub. It holds a theme scope (light, dark or both), up to six fixed logo slots plus custom named images, semantic colour variables with a light and a dark value each, named type styles with a Google Fonts family, a base radius with a derived sm/md/lg/xl scale, an icon pack, and a list of markdown documents for the parts of the brand that are prose. Every section is optional. An empty kit shows a teaching empty state, and Preview only renders what has content.
Any org member can read it; owners, managers and editors change it inline in Edit mode, with a debounced autosave. The Brand Kit feature flag is on by default and enforced on the backend as well as the route. It is org configuration rather than content, so it carries no client/internal visibility toggle.
Two things make it more than a settings page. First, the export dialog copies the tokens as CSS variables (the root variables plus the dark override), JSON, or a Tailwind theme-extension snippet, so a client's own site can consume the same values we do. Second, and this is the part I care about, downstream surfaces inherit the kit as their default theme. Every form, every Spotlight link page and the Support widget resolve the kit's colours, fonts, radius and theme mode through one shared resolver. Change the primary colour once and every form that hasn't overridden it restyles.
You can open a populated kit in the browser-only showcase, no login: Palazzo Marzano's brand kit. The feature page is at sharphaw.digital/features/brand-kit.
How it works
Three decisions carried most of the weight.
Inheritance is a name heuristic, and I say so. Colour entries in the kit carry no semantic role. A colour has a name, a light value and optionally a dark value, and nothing more, because forcing a role taxonomy onto a designer's palette produces a form nobody fills in. So the surfaces that inherit the kit map by name: a colour called "primary" or "brand" becomes the accent, "background" or "surface" becomes the background, "foreground" or "text" becomes the text colour. The honest consequence is that renaming a colour can change how a form looks. We documented that rather than hiding it, because the alternative is a schema nobody fills in.
Theme scope is destructive, on every write path. Switching a kit from "both" to light-only clears the dark values instead of hiding them. That rule is enforced on the server on every save, whether the change comes from the hub or the API, so a kit can't be left inconsistent by either. Because it deletes data, narrowing the scope opens a confirm dialog that names exactly what goes ("the dark value from 4 colours, and the logo — alternative image"), computed from the current draft.
The kit never auto-renders a logo. A logo slot can point at a Media Center asset or at a Studio frame. A frame-backed slot stores a reference, so editing the frame in Studio updates the brand asset, but the image shown is the frame's last published render, and that render can be older than the frame. Server-side rendering has known font and wrap drift against the editor. Silently healing a brand asset with a slightly wrong render would be worse than an honest badge, because the thing being altered is the client's identity. So every slot reports whether its render is ready, stale, missing or a video, and a stale one shows an amber "Out of date" with an "Open in Studio" link. The share image only uses a frame-backed image while its render is fresh, because social platforms cache a share image hard.
Adding frame-backed slots needed no migration: a slot value is either an asset or a frame reference, the two are told apart by shape, and every pre-existing kit kept working unchanged.
The export is deliberately boring. A kit in "both" scope with a colour, a radius and a heading style exports as a flat set of CSS variables: the colour, the radius and its derived small, medium, large and extra-large steps, the corner smoothing, the heading font and size, plus a dark override that only carries the values that differ. The dark override appears only in "both" scope, and only when at least one colour has a dark value. A light-only or dark-only kit exports a single flat set, because there is nothing to switch between.
What it doesn't do
Brand Kit is smaller than a design-system tool, and it should stay that way. There are no components, no Figma or Storybook sync, no versioned releases of the system. It is not an asset library either; Media Center is, and the kit only references it. The brand documents are a markdown textarea with a preview tab, not the collaborative block editor the rest of SharpOS uses. Studio and Pages don't consume the tokens yet. The squircle preview relies on the CSS corner shape property, which only recent browsers render, though the smoothing value always exports as a corner smoothing token for whatever tool reads it next.
If you run a design team with a component library and a governance process, keep it. Brand Kit is for the business that has one brand, six surfaces we run for it, and nobody whose job is to keep them aligned. The kit is the alignment.
Where it sits in the service
We use it inside Conversion-First Websites: the site's tokens live in the kit, the forms on the site inherit them, and the client can read the same kit in SharpOS at any hour. That is the whole pitch, and it fits in one sentence.
The question I have for you
Where does your brand actually live today, and what reads it? If the honest answer is "a PDF, and people", I'd like to hear which touchpoint drifted first.
This is part of the series SharpOS, surface by surface. Part 1 is the ledger itself: We replaced a 12-tool client stack with one workspace we built.
Top comments (0)