Can our marketing team publish without waiting on a developer?
If every blog post or page change needs a developer, content slows to the speed of the engineering queue. What a publishing setup should let marketers do alone, what should stay with developers, and the CMS we built and now run our own hub on.
- Split the work: marketers own content, developers own templates and components.
- A good CMS has roles, preview, and per-page SEO and FAQ fields, not just a text box.
- Structured fields beat a single body of text: tags, FAQs, takeaways and dates are data, not formatting.
- A reusable component set lets marketers add tables, callouts and CTAs without code.
- We disclose a link: we co-founded CrawlTheory, whose CMS we ported to our own hub.
Quick answer
Yes, if the CMS is built around the page types marketing publishes: posts, guides, case studies, FAQs, tags. Marketers should be able to draft, tag, add FAQs, set SEO fields, preview and publish alone, with roles that stop a mistake reaching the live site. Developers keep templates, components and the data model. If a headline change needs a ticket, the setup is wrong.
Disclosure: our co-founder Aadarsh Mishra also co-founded CrawlTheory, an SEO publication. We built CrawlTheory’s CMS and reuse its design here. We say so up front so you can weigh it.
The short answer
Marketing should be able to ship words, structure and metadata on its own. Developers should keep the parts that can break the site. The line between the two is the whole design.
Why marketing heads ask this
Because the usual alternative is a queue. Every new post, FAQ or CTA change becomes a ticket, and launch dates move to the developers’ sprint. Over a quarter that costs more than the CMS did. The worry on the other side is just as real: if marketing can publish anything, who stops a broken page?
What good looks like
What marketers should do alone
- Draft, edit, preview and publish a post, guide or case study.
- Tag it by topic and, where relevant, by industry.
- Write the headline, the SEO title and description, and the FAQs.
- Add tables, callouts, call-to-action blocks and downloads from a set of ready-made components.
- Set and update a last-verified date.
What should stay with developers
- Page templates and the component library.
- The data model: which fields exist and what they mean.
- URL rules and redirects at scale.
- Anything that changes how pages are generated or served.
What the CMS needs to make that split safe
| Need | Why |
|---|---|
| Roles (full admin, editor, viewer) | An editor can publish content but can’t change the structure of the site |
| Preview before publish | Mistakes are caught in a draft, not on the live page |
| Structured fields for tags, FAQs, key takeaways, dates and authors | They become data a template can reuse, not formatting someone has to repeat |
| A fixed component set | Marketers can build a rich page without writing code |
| Per-page SEO fields | Title, description and canonical are set where the content is written |
| A status flow (draft, review, published) | A page isn’t live until someone decides it is |
How we did it
CrawlTheory is a publication Aadarsh co-founded, built on Next.js and Supabase with an admin CMS. The GarunaCDX resource hub reuses its tables and admin. Neither has a recorded traffic or AI-citation result.
For CrawlTheory we built an admin CMS around the content a publication actually produces. We then ported its design to this resource hub: the tables live in their own schema, apart from the main site’s data. The hub CMS has three roles (super admin, editor, viewer), a case-study editor with blocks such as charts and before-and-after views, industry tagging, FAQs attached to each post, and a last-verified date and peer-reviewer field per post.
This page is written to fit that structure, using the hub’s component set: quick-answer boxes, callouts, tables, accordions and call-to-action blocks.
What we haven’t shown. We have no traffic number and no record of being cited by an AI search tool, for either site. We also have a known gap: the last-verified date and reviewer are stored but not yet shown on the page. It’s on our list. A CMS that lets you publish fast does not make the content good. That part is still editorial work.
Where this doesn’t apply
If you publish four pages a year, a developer-maintained site is fine, and a custom CMS is overbuilt. If your team already works well in a mainstream CMS, don’t replace it for the sake of it. Switching costs real time. And a CMS can’t fix a slow approval process: if every page needs five sign-offs, tooling won’t help.
Questions to ask any vendor, including us
- Which content types will my team publish alone, and which will still need you?
- What roles exist, and what can an editor not change?
- Can I preview a page exactly as it will look when published?
- Where do FAQs, SEO fields and dates live: as fields, or as text inside the body?
- What happens to my content if I leave: can I export it?
Next: will the site get found: a technical SEO and AI-search checklist and should one vendor do both the tech and the go-to-market. Part of the guide Buying custom software and hiring a tech vendor.
The description of the hub CMS comes from our own repository and migration notes; the CrawlTheory description comes from our project notes. Both are tracked in our claim ledger. Aadarsh co-founded CrawlTheory, which is why we disclose it. We hold no traffic or citation data. No figure on this page comes from a third party.
More by GarunaCDX
Let's talk about your build.
Tell us what you are building. A founding engineer replies within one working day with how we would approach it.
