What a client portal is for after the brand is delivered

A brand asset portal is the place logos, tokens, documents, and project updates stay findable after the identity is delivered. The delivery is not finished when a folder changes hands. It is finished when the next person, six months later, can open the current logo without asking who has the latest file.

A zip in a chat thread fails that test on a schedule. Someone downloads it, someone else edits a copy, and the thread scrolls away. The portal is a room with a name. People can return to it. Google's guidance on helpful content says that among experience, expertise, authoritativeness, and trustworthiness, trust matters most, and that it helps when readers can tell who created the work. A portal answers a smaller version of that question for your own team: which file is the one the studio stands behind, and where the notes live.

What belongs in the room

Keep the set short enough to scan.

• Logo files, named for the surface: light, dark, single color, favicon. The current version only, with a previous version archived if a contract or a printed piece still needs it.
• Color and type decisions: the hex values, the families, the sizes, and the few tokens if you have named them.
• The short voice page: the sentences you will say, and the ones you will not.
• Documents the team will open again: the scope, the content map, the way to edit the site, the accounts they own.
• Project updates after launch: what changed, what is waiting, and where to look.

Each item needs an owner and a date. An undated file called "logo final" will be treated as optional. A file called "logo, light ground, March 2026" can be used with a straight face.

Images belong as files, with the alt text or the caption notes if those were part of the work. A brand that spent care on photography loses it when the only copy is inside a layout tool no one else can open.

What stays out

Keep credentials out of the brand room. Passwords, private keys, and customer data belong in a password manager or the host's own access controls. A portal full of secrets becomes a risk, and people stop using it for the ordinary files because it feels dangerous to share.

Keep half-drafts out of the current shelf. Explorations are useful during the project and confusing after it. Archive them under a label that says they lost, or leave them in the design file. The current shelf should contain work you are willing to see on the site tomorrow.

Keep the full chat log out. Decisions that matter get written as a note: what was chosen, and what it replaced. A transcript forces every new teammate to become an archaeologist. They will not. They will guess.

How Hanabi's portal is meant to be used

Hanabi's client portal holds brand files, docs, and project updates after delivery. That is the whole job. It is the concrete version of the room described above, so a client is not reconstructing the brand from email. The same engagement that designs and builds the site can leave the files where the team will still find them when the studio is busy on the next task.

Use it as the canonical shelf, and point other tools at it. The repository can link to the portal for logos and written notes. The CMS can hold the words of the live site. The portal holds the source files and the decisions those words came from. Three homes, each with a job, stay manageable. Seven homes, each with a partial set, do not.

Updates belong in the portal when they change what the team should do next. "The accent hex changed, and the button component is updated in the repo" is an update. "Hope you are well" is not. Write the note in the same plain voice as the rest of the brand. The portal is a brand surface too. A chaotic updates feed teaches people to ignore it.

Access should match the team you actually have. The founder, the person who edits the site, and the engineer who implements tokens need in. A wider guest login is useful for a printer or a contractor with a dated need, and it should expire. Removing access when someone leaves is part of delivery, in the same way transferring the domain is part of delivery.

Names, versions, and the old logo

The painful moment is the second version. You change a wordmark, or you correct a color, and a sales deck from last quarter is still in the wild. The portal cannot pull every deck back. It can make the current file obvious and the old file visibly old.

Put current work at the top. Move replaced files into an archive with the date they stopped being current. In the update note, say what changed in one line, and say whether printed pieces are allowed to run down their stock. Teams get into trouble when both versions look equally official.

Match names to the engineering page if you have one. If the guidelines call a file logo-dark.svg, the portal should use that name. A beautiful display name in the portal and a different name in the repo guarantees someone will attach the wrong one.

Ask, once a year or when a new hire joins, for a single check: open the portal and find the logo, the text color, and the latest project note. Time it. If it takes more than a few minutes, the shelf is too deep, or the names are coy. Flatten it.

The week after delivery

In the week the project hands over, walk the portal with the person who will use it. Download the logo. Open the editing note. Find the latest update. That walk is short, and it reveals missing files while the work is still fresh. A portal that is introduced only by a link in a farewell email becomes another tab people mean to explore.

Agree who may replace a file. The founder may approve a new logo. The editor may replace a photograph. The engineer may update a token note after a release. Write those roles in a sentence at the top of the room. Shared ownership without a sentence becomes nobody's job, and the archive rots.

Keep the studio's role explicit. Some teams want a place to receive files and nothing more. Some want updates to continue as the site changes. Either arrangement can be clear. An arrangement that is only implied will be relitigated the first time something breaks.

The portal is a maintenance tool. It does not replace a person who can approve a change, and it does not keep a system alive by existing. Someone still has to put the new file in the right place and say that it is current. Hanabi's services include that handoff, with the portal as the shelf for files, docs, and updates. How the kit stays in use after the first month is the subject of How a brand kit stays alive after launch.