Building a Blog and CMS Workflow That Non-Technical Teams Can Use
A healthcare client's marketing team was publishing blog content by emailing Word documents to a developer, who'd manually convert formatting, source images, and hand-code each post into their WordPress theme. Publishing cadence had dropped to about one post a month, not because they lacked content, but because the process had a hard bottleneck on developer availability.
We moved them to Sanity as a headless CMS, chosen over a page-builder-heavy alternative because the client's content model was genuinely structured — posts had consistent fields (author, category, related posts, SEO metadata) rather than freeform page layouts, and a structured content model meant the frontend could stay a clean Next.js site rather than accumulating page-builder cruft.
The editor experience needed real attention, not just API wiring. We built a live preview that rendered the actual production component tree inside the Sanity Studio as the marketing team typed, since their biggest complaint about the old system wasn't the workflow — it was not knowing what a post would actually look like until a developer published it. Getting live preview working meant sharing the exact React components between the Studio's preview pane and the production site rather than maintaining a separate preview renderer.
We added guardrails rather than open-ended flexibility. Image uploads auto-generate responsive variants and enforce a minimum resolution with a friendly error message rather than silently accepting a blurry 400px image. SEO fields (meta description, canonical URL) are required before a post can be marked ready for review, with character count validation, so the marketing team catches issues before a post ever reaches a developer's queue.
The publishing workflow itself has three states — draft, in review, published — with review requiring a second team member's sign-off inside Sanity's built-in workflow, which replaced an ad hoc Slack approval process that had no audit trail.
Nine months after launch, the client publishes 3-4 posts a week without developer involvement for routine content, and the dev team's only recurring CMS work is adding new content types when the marketing team's needs genuinely expand — which is the right amount of involvement for a tool that's supposed to remove them from the loop.
