One content table. Every type your brand publishes. SEO that doesn't drift.
m18t's content workspace covers blog posts, news posts, web pages, help articles, social posts, and any custom content type your brand needs — in one rich-text editor, one status workflow, one SEO model. Switch brands and the whole table re-shards. No copy-pasting.
Five tools per brand, three meanings of "in progress," zero consistency.
Most product teams maintain a separate workflow per content type. Blog posts in WordPress. Social posts in Buffer. Help articles in Intercom or Notion. Web copy in a Figma file. Each has its own table, its own status meanings, its own SEO rules, its own publishing flow.
The result: the same brand publishes "My Brand | Home" on one page and "Home - My Brand" on another, because three people on three tools made three different micro-decisions. The SEO defaults drift. The status vocabulary diverges. The content calendar lives in yet another tool. Multi-brand operators multiply the chaos by every brand they run.
m18t collapses this into a single content table with type-extensible defaults per brand. One editor. One status set. One canonical SEO model. Per-brand consistency, no copy-paste discipline required.
Five steps from idea to live.
- 1
Define your content types per brand
Out of the box: blog-post, news-post, web-page, help-article, social-post, video-post. Need a case-study for one brand and a recipe for another? Register them in Studio config. Each type gets its own SEO defaults — URL prefix, schema.org type, meta-title template, fallback OG image, supported locales.
- 2
Draft in the unified editor
A rich-text editor with full table, list, code-block, blockquote, task-list, image, and link support. Same editor for every content type. Drag in assets from your brand's media library; they get attached as either cover or inline.
- 3
Configure SEO once per (brand × type), override per piece if needed
Your per-brand × per-type SEO defaults flow into every piece you create of that type. Per-piece overrides are available but rare — that's the point. Consistency is opinionated; deviation is deliberate.
- 4
Publish across channels
One piece publishes to: your CMS (Strapi today), Facebook, Instagram, your blog target, or any custom channel you've registered. Per-channel state is tracked on the content row. Sync log captures every push.
- 5
Track status with vocabulary that fits
The same ten-status set across the platform, but each shows under the right label for each content type. "Production" reads as "Published" for a blog post, "Indexed" for a sitemap entry, "Live" for a web page. Same status, native vocabulary.
The capabilities, listed honestly.
One rich-text editor for every content type
Tables, code blocks, task lists, blockquotes, images, links, hard breaks — all supported. No per-type editor mismatch.
User-defined custom content types per brand
Ship case-study, release-note, recipe, interview, or whatever your brand publishes. Each gets its own SEO defaults.
SEO indices that prevent drift
Path prefix, schema.org type, robots, meta-title template, OG fallback — set once per (brand, type), apply to every piece.
Locale groups for translation siblings
Two pieces in different locales linked as siblings. CMS push handles multi-locale correctly (Strapi v5 localization endpoint).
Brand-scoped from day one
Content is always tied to a brand. Brand switcher re-filters the whole content table.
Status rollups with per-type vocabulary
Same status, native label per artifact. Production reads as Published, Indexed, Live, Hired — depending on the artifact.
Linked artifacts
Attach docs, decisions, notes, annotations to any piece via the polymorphic artifact relations.
Channel-aware publish state
Per-channel publish status, engagement counters, sync log — all on the same row.
Content doesn't live in isolation.
It's the surface where your product's spec gets translated into stories. m18t makes that translation structural.
Generate brand-aware cover imagery and social graphics for every content piece. The AI knows your brand colors and references the content piece directly.
Ship one canonical piece to Facebook + Instagram + your CMS in one click. Per-channel state tracked.
Use your managed AI prompts inline in the editor. SEO prompts can't even hallucinate canonical URLs because the path is auto-injected.
Link content pieces to the features they describe. Marketing stops drifting from product because both live in the same workspace.
If you run more than one brand, the brand switcher in the sidebar re-shards the entire content table — same UI, different world.
What's here today, what's rough, what's coming.
Solid today
- — All six default content types working
- — User-defined custom content types per brand
- — SEO indices with default fields and per-piece overrides
- — Locale groups + multi-locale CMS push
- — Status rollups with per-type aliases
- — Linked artifacts
- — Channel-aware per-channel publish state
Rough today
- — Type-specific UX edge cases (video-post attachment, social-post per-platform preview)
- — Bulk operations across multiple pieces (basic, can be deeper)
Coming
- — Inline preview per target channel before publishing
- — Bulk schedule and bulk status changes
- — Auto-publish loop (cron + status + due-date)
- — More CMS adapter targets beyond Strapi
The brand switcher re-shards the content table.
If you run multiple brands, the content table re-shards on every brand switch. Each brand carries its own content types, its own SEO indices, its own status aliases (if you want them to differ), and its own integrations. An agency with thirty client brands runs the same UI as a solo founder with one brand — the data behind it just changes.
More on the multi-brand wedge → /solutions/multi-brand
Frequently Asked Questions
Try the content workspace.
Free during beta. Bring your AI key when you want generation. The founder fixes bugs the same week.