How a brand kit stays alive after launch
A brand kit stays alive when one person owns changes and the files live where the team already works. A zip file in a chat thread will fork.
Design system maintenance is a person and a place. Someone has to own changes after launch. The current files have to live somewhere the next teammate can find without asking in a chat thread. A portal, or a short kit page, does that job. A zip file named final-final-v3 does not.
Launch is the moment the system is most accurate and least tested by time. The week after, someone needs a slide, an ad, a new empty state, a partner logo lockup. Each request is reasonable. Each one can add a color, a type size, or a stretched mark. Maintenance is the habit of folding those requests back into the kit, or refusing them, while the original decisions are still easy to see.
What decays
Logos decay by export. A mark gets pasted into a doc, recolored for a dark photo, and that recolor becomes the version people forward. Type decays by substitution. The font is not installed on a contractor's laptop, so a nearby family takes its place for one landing page, and the landing page performs well enough that nobody restores the face.
Color decays by convenience. A campaign wants a brighter accent for a week. The week ends and the accent remains in three banners and one button. Components decay when a screen needs a special case and the special case is copied forward as if it were the new default.
None of this looks like a revolt. It looks like work getting done. The kit goes stale because the stale version was faster to grab. Maintenance makes the current version the fastest one to grab, and makes the owner easy to ask.
Accessibility decisions decay the same way. The W3C's Web Content Accessibility Guidelines set the expectation that content stays perceivable and operable, not only on the day you checked contrast. A new banner with pale type on a photograph can undo a token that was careful. Put that banner through the same pair check as a button. Maintenance includes the pairs, not only the logo clearance.
Someone owns the change
Name the owner in a sentence people can repeat. "Changes to type, color, logos, and shared components go through Amina." If Amina is the founder, the job still has to be real: a reply that says yes and updates the source, or no and points at the existing piece. Silence is how the zip file returns.
The owner does not have to draw every exception. They have to keep the source honest. A contractor can design a campaign frame. The owner decides whether its new color enters the kit or stays inside that frame with an expiration. Local exceptions are allowed. Unrecorded exceptions become the next brand.
On a Hanabi engagement, the handoff is built for this. The studio designs and builds, and the client portal holds the brand files, the docs, and the project updates after delivery. The portal is the place. It does not replace the owner. It gives the owner a shelf that is not a laptop.
Write down how a change is requested, in one line. A message with the screen, the decision you want, and why the current kit failed. The owner answers in the same thread and, if the answer is yes, updates the file before the thread scrolls away. If the update waits for a monthly cleanup, the team will ship the unofficial version in the meantime and you will be cleaning up a fact, not a proposal.
A home that beats a folder in chat
Pick one home and delete the temptation of the others. The home can be a short page in the repository: logos, token names, type, a picture of the components, and a link to the Figma file that is actually current. The home can be the portal, with those files plus the notes from the project. It should not be both, unless one is clearly the copy and people know which.
The page stays short or it will not be opened. Engineers open a page that gives them the file, the hex, and the type settings. They do not open a brand film to export a mark. Founders open a page that shows the logo on light and dark and says the minimum clear space in one picture. Give each of them that, and stop.
Retire old files out loud. When the mark changes, the previous SVG is removed or moved to an archive labeled with a date. Leaving both in the same folder guarantees the wrong one will be used on a Friday. A chat attachment is the worst archive, because search will surface it with the same confidence as the real file.
A change process small enough to happen
Use a process you can run on a tired afternoon.
- The request names the screen and the rule that broke.
- The owner says local exception, kit change, or refusal.
- A kit change updates the source the same day: Figma, code, and the portal or kit page.
- The person who asked uses the updated source, not their private export.
That is the whole loop. A design-system committee with a monthly agenda will not meet during launch month, which is when the kit is most at risk. A single owner with a same-day update will.
Review drift when you already have the work open. If you are looking at a new feature, look at its colors and type against the kit before you approve it. A separate maintenance sprint, scheduled in the abstract, loses to whatever the company is selling that week. Attach the check to work you are doing anyway.
Keep a tiny log. Three lines per change: the date, the decision, the reason. The log lives on the kit page. Six months later, when someone asks why the accent moved, you have an answer that is not a memory. The log also slows casual changes. A decision you have to write down feels more expensive, which is appropriate, because a token change is expensive.
What not to freeze
Maintenance is not a promise that nothing can change. A kit that refuses every request will be routed around. The product will grow a real need: a status color, a denser row, a lockup for a partner. Fold those in. The system stays alive because it can accept a decision, not because it was perfect in the export you made at launch.
Freeze the things that are the brand. The name, the mark, the type pair, the idea of how loud the interface is. Let the component list grow when repetition earns it. A new icon, requested once, can stay in that screen. A new icon, requested three times, belongs in the set, drawn on the same grid as the others.
If the home for those files is still a thread, the next piece is about the place itself: what a client portal is for after the brand is delivered. It is the shelf for logos, tokens, docs, and updates.
When you want that shelf set up as part of the work, see Hanabi's services. The studio's handoff includes the system and a portal so the kit is still findable after the launch week ends.
Frequently asked questions
Who should maintain a design system after launch?
Name one owner. It can be the founder, a designer, or the studio you keep in touch with. The owner accepts or refuses changes to type, color, and components, and updates the place everyone else downloads from. A system with no owner becomes a zip file within a month.
Where should the current brand files live?
In one place the team can open without asking who has the latest. A short page in the repo, or a client portal with the logos, tokens, docs, and project notes, beats a folder passed around in chat. When a file changes, it changes there, and the old one is retired.
How often should a small team review the system?
Review it when the product changes, not on a ceremonial calendar. A new feature that needed a new component is the review. A quarterly pass is useful only to catch stray values that slipped in. If nothing changed and nothing drifted, the meeting can be five minutes.
Sources and further reading
Written by
Hanabi
Hanabi is a product design and web development studio. The studio writes about clear websites, brand systems, and product interfaces for founders.
