Choosing a CMS when the marketing team is small

Choosing a CMS for a small marketing team is a staffing decision that happens to involve software. Ask who edits, how often the words change, and whether a draft must be approved before it is public. The product name matters after those answers, not before.

A team of one founder and one marketer does not need the CMS a newsroom uses. It needs a quiet place to change the pages that actually change, and a reason to leave the rest alone. The wrong tool makes every sentence feel like a project. The right tool makes the weekly edit boring.

Who edits

Name the person. If the founder is the only editor, the tool has to be learnable in an afternoon and hard to break. If a marketer edits and an engineer reviews, you need roles, or at least a draft the engineer can open. If the studio is the only party who will ever touch the words, a CMS can be a false comfort. The repository, with a preview link, may be the more honest editor.

Write the name next to the page type. Homepage: the founder, twice a year. Blog: the marketer, when there is something to say. Job posts: whoever is hiring, in a structured form. Product descriptions: the person closest to the offer, with someone else reading it before it is public. A tool that assumes a department will embarrass a team that is three people.

Google's helpful-content guidance is a useful test of the person, not only the software. People-first pages are created for an audience you already have, with a clear purpose, and they should leave a reader feeling they learned enough to act. The same guidance asks whether it is obvious who created the content. A CMS login called "admin" and a byline that does not exist fail that question even when the buttons are pretty. Put a real name on the work, and give that name an account they control.

How often the words change

Frequency decides whether the words belong in a CMS or in the code.

Pages that change a few times a year can live in the repository. The cost of asking an engineer, or the studio, to change a headline is real, and it is often smaller than the cost of a flexible editor nobody trusts. A services page, an about page, and a short list of projects are usually in this group at the start.

Pages that change every week need an editor. Articles, a changelog, event notes, a small set of answers you update when the product changes. If publishing that kind of page requires a pull request, it will not happen, or it will happen in a rush the night before a launch. Give those pages fields: title, summary, body, date, and a hero with alt text.

Be honest about the blog you do not have yet. Buying a full editorial suite for a journal you might start is how teams end up with an empty CMS and a homepage that is still hard to edit. Start with the pages you will touch this quarter. Add the journal when the first three pieces are ready to draft.

Whether drafts matter

A small team still needs a pause between writing and publishing. The pause is a draft. The founder writes, the other founder reads, then it goes live. Or the marketer writes and the person responsible for the offer checks the claims. Without drafts, the only states are hidden and public, and people publish early because the preview was a production trick they were afraid to use.

Drafts matter more when the page can hurt you. Pricing, a customer story, a comparison, anything a stranger might quote. Google's quality questions ask whether content has factual errors a reader could verify, and whether it looks hastily produced. A draft is how a small team gets a second pair of eyes without hiring a desk.

Hanabi's own writing sits in Payload for this reason. Articles are drafted, reviewed, and left unpublished until they are ready. That writing desk is separate from the client portal. The portal holds brand files, documents, and project updates after a delivery. Mixing those jobs makes both worse: a marketer hunting for a logo inside a blog admin, or a client opening a CMS to find a PDF. Separate tools, named for the job, are easier to keep.

Your project might use Payload, or another editor with the same shape: structured entries, drafts, and a public site that reads from them. The brand of the CMS is secondary to the draft. If the tool publishes the moment you save, and you wanted a review, it is the wrong tool.

What the editor is allowed to change

Give fields for the things that change. Headline, body, image, summary, and the one action. Keep the layout in the design system. A small team with absolute freedom on every pixel will reinvent the homepage by Thursday, and the next page will not match.

This is the trade the next piece takes on directly. How to keep a site editable without a page-builder mess is the argument for structured fields over a free canvas. Read it when the demo you were shown is mostly dragging boxes.

Permissions can be simple. One role that can draft, one role that can publish, and a shared understanding of which role the founder is in. Complicated workflows are how a three-person team stops publishing. Two steps are enough: write, then approve.

Also decide what is not in the CMS. The global navigation, the footer, and the type styles should change rarely, in code, by someone who can see the whole site. Letting every post invent a new accent color is how a brand system dies in the editor.

A choice you can explain in one paragraph

When you have the three answers, the choice is usually obvious.

• One editor, rare changes, no public journal: keep the pages in the repository and review them on a preview URL.
• A marketer publishing on a rhythm, with someone else checking claims: use a CMS with drafts, structured fields, and two roles.
• A studio still in the engagement: the client should already have their own logins, so the tool does not become a dependency that ends when the contract does.

Ask for an export. If you leave the CMS, the words should come with you in a format another site can read. Ask who pays for it and who can reset the password. Ask to see a draft become a preview without touching production.

Hanabi's services include the site and the decision about where its words live, so the editing path is part of the build rather than a plugin chosen after launch. Bring the name of the person who will edit, and how often. That is the brief that makes the CMS choice a short meeting.