One design system for the website, proposals and LinkedIn

It started with the website. Its colours were written straight into the stylesheet as hex codes. That was fine while the website was the only thing we had.

Then we needed proposals. The proposal template got its own colours and a different font. Then came slides, with a third set. Each file looked fine by itself. Put a proposal next to the website and they didn't match.

The obvious fix is a cleanup: sit down and make all three match by hand. But that only lasts until the next template gets made from somebody's memory of the brand. As long as each project has its own copy of the brand, the copies will drift apart again.

The design system is one folder in our company knowledge base, the same place the rest of the company's written knowledge lives. I kept it small on purpose. If it's too big to remember, people stop looking things up and start guessing again. It has four things in it.

• Tokens. A token is a decision with a name. So the file doesn't say "use #1A4FD6", it says "primary" and gives the value once (that hex code is made up for this example). There are tokens for colours, for type (which fonts, which sizes for headings and body text) and for spacing (the gaps that repeat between blocks).
• Logo files. The approved versions, plus a few lines on clear space and minimum size. The rules do more work than the files do. A logo file with no rules next to it ends up stretched, or placed on a busy photo.
• Templates. Two kinds for now: carousels for LinkedIn and proposals. Each template already uses the tokens, so whoever fills one in writes the words and leaves the styling alone.
• Usage rules. One page. Which heading style is the default, which colour is for the main button or call to action, what never to do with the logo.

This is the rule everything else depends on. A project doesn't get its own copy of the design system. It gets a link to the shared folder.

On my machine the link is a symlink, a small file-system entry that points at another folder. Inside each project there is an entry that looks like a normal folder (I'll call it design-system here), but its contents are the shared one. Change a token in the shared folder and every project sees the new value, because there was only ever one file.

The rule has to hold for every project, including the quick ones. A single local palette kept "just for this deadline" is how the drift started in the first place.

For an existing project, the move is: find every local copy of colours, fonts, logos and templates, replace them with the link, and where a local value differs from the shared one, take the shared one unless someone can say why it should differ. Most of the time the difference is an accident.

Somebody has to own the shared folder. In a small company that's one person who approves changes to tokens, logos and templates. Everyone else uses them and sends suggestions.

Symlinks have limits, and it's better to know them before you start.

A link only resolves on a machine that has the shared folder at the place the link points to. A colleague who clones one project without the knowledge base gets a link to nowhere. So does a build server that only checks out the website's repository. Before you rely on the link for a deployed site, check how that site is built. You may need a build step that copies the tokens in at build time. That step is still a copy, but a script makes it fresh on every build, and nobody edits it by hand.

Git stores a symlink as a link, not as the folder's contents. On file systems without symlink support, Git checks them out as small text files that contain the path. If part of your team is on Windows, test this on one machine first.

And some tools can't follow a link at all. A slide deck or a design file can't read tokens from a folder. For those, the template in the shared folder is the source, and you start every new file from it.

A rule that depends on people remembering it won't last. So there's a check script. It goes through the projects and asks one question of each: does this project link to the shared folder? If yes, it passes. If no, it fails and names the project.

It doesn't judge design. It can't tell you whether a page looks good. It only catches the moment a project stops using the shared source, which is the moment drift starts.

Run it where it's hard to skip. Checks like this work well as a git hook that runs before a commit or a push. The core of it is one line per project. This is the idea, not my actual script:

test -L design-system && test -d design-system/ || { echo "design-system is not linked to the shared folder"; exit 1; }

Social images drift faster than anything else. They're made often and in a hurry, and each one tends to start from last week's file.

So ours are designed with the design system attached. In practice that means the tokens, the logos and the carousel template are in front of whoever, or whatever, makes the image before the first frame is drawn. The finished images are exported into one folder in our outreach workspace, so the posts and their images sit together.

Keep the number of templates low. A cover, a content frame and a closing frame cover most carousels. Every extra template is one more thing to update when a token changes.

Most of this work is tedious, and an AI coding agent such as Claude Code is good at tedious. It can collect every colour and font in use, draft the tokens, create the links and write the check. Choosing which blue is the real one is your job and the designer's.

So split it into two passes. In the first, the agent only takes inventory: every colour value, every font, every spacing value it finds across the website, the proposal templates and the slides, and where each one is used. You and the designer go through that list and pick the survivors.

In the second pass, the agent builds the folder from your decisions, links each project and runs the check. The prompt below covers both passes and makes the agent stop in between. Swap in your own paths.

Goal: move our brand decisions into one shared design system folder and link every project to it.
Inputs: the website stylesheet at [path], the proposal templates at [path], the slide files at [path], the logo files at [path]. The shared folder will live at [path in our knowledge base].
Pass 1 (read only): list every colour value, font and spacing value in use, grouped by where it appears, and mark the ones that are near-duplicates of each other. Change nothing. Stop and show me the list.
Pass 2 (after I tell you which values to keep): create the shared folder with tokens for colour, type and spacing, the logo files, one carousel template, one proposal template and a one-page usage guide. In each project, replace local copies with a symlink named design-system that points to the shared folder. Write a check script that exits with an error and names the project when that link is missing or broken.
Constraints: do not delete anything without showing me first. Do not invent new colours or fonts. Tell me about any project where a symlink will not work, such as one that is built on a server.
Definition of done: the check passes for every project, and you give me a list of every value you replaced and what replaced it.

No client is going to ask about your tokens. What a client sees is a website, then a proposal, then an invoice. If those look like they came from one company, nobody notices, and that's the goal. If the proposal's blue is off and the font is different, it reads as a small sign of carelessness, in the one document where you're asking for money.

There's a second benefit, and it's for us. When the styling is already settled, a review of a proposal can be about the offer and the wording. And a freelancer who joins for a month starts from the folder, not from a screenshot of the homepage.

I can't show you a before and after in numbers. The setup is new and I haven't measured anything. If you want help doing the same, get in touch or read how I work with founders.