Editing Workflow
How content updates flow through a Planted Sky build.
A common worry about a custom build: "Will I need a developer for every little change?" The short answer is no. Here is the longer answer, with the workflow we use to keep your team self-sufficient on day-to-day edits while protecting the parts of the site that need protecting.
Platform-agnostic philosophy
This page describes the workflow on a headless build, which is our default. The same philosophy applies to a WordPress build with the right page builder approach. If your project is on WordPress, the section-based discipline, the brand guardrails, and the editor controls described here all transfer. The platform changes; the philosophy does not. See our WordPress builder guide for the WP-specific take →
🥣 The Goldilocks problem
The sweet spot we aim for.
Every CMS sits somewhere on a spectrum from "locked down" to "free-for-all." Locked down is too rigid. Free-for-all is too loose. Structured flexibility is the just-right middle - editors can change anything they should be able to change, without being able to break the site.
Locked down
A pure static site is built once and served as files. Every text change, image swap, or new page goes through a developer. Fast and secure. Useless for a team that wants to publish on its own schedule.
Structured flexibility
Sanity gives editors a form-based dashboard. The fields, options, and pre-approved layouts are defined once during the build. After that your team adds pages, swaps photos, edits copy, schedules posts, and manages the navigation - all without touching code or waiting for us. The pieces that need engineering oversight (new section types, brand-level redesigns, custom integrations) come back to us through a clear workflow.
Free-for-all
Site builders give editors total layout control. Powerful in the right hands, but it usually means brand drift, accessibility regressions, mobile breakage, and slower pages over time. Total freedom is total responsibility.
Our job: the right building blocks.
Before any of this works, we have to dig deep and figure out exactly what your team needs to publish - today and a year from now. That discovery is not a side task. It is the work.
Any agency worth hiring asks the right questions before writing a line of code. What kinds of pages will you publish? What lives on each one? Who edits what? What changes weekly, what changes once a year, what never changes? The answers shape every schema, every component, and every field your team eventually sees in Sanity.
If we miss something here, you feel it for years. If we get it right, your team has everything they need - with the guardrails baked in from day one.
What we model into your build
- Blog posts and editorial content
- Testimonials and case studies
- Course content and curriculum
- Team bios and author pages
- Research articles and white papers
- Programmatic landing pages
- Service and product directories
- Dynamic content (events, news, openings)
- Anything specific to how you actually operate
Same idea, different vocabulary
You may have heard this called a design system, a component library, a design library, or atomic design (Brad Frost's atoms / molecules / organisms framing). Different names, same concept: a vetted set of reusable building blocks that compose into your full site.
A typical block library, visualized
A starter set of the most common reusable blocks. Each one is built once, accessibility-checked once, performance-tuned once - then reused everywhere it fits.
-
Hero
-
Section heading
-
Feature grid
-
Image + text
-
Testimonial
-
Stats row
-
FAQ accordion
-
Pricing card
-
CTA strip
-
Logo wall
-
People grid
-
Article feed
-
Pull quote
-
Comparison table
-
Newsletter signup
-
Custom blocks for your business
Granularity: what each block actually lets you control.
Every block has its own set of editor controls. Some controls are about content (which testimonial, which posts), some are about layout (one-up close-up vs three-up grid), some are about brand tokens (which approved color, which heading level). The discipline upfront is deciding which knobs to expose and which ones to lock down so your team has the right amount of control - no more, no less.
Content source
Where the content comes from
For dynamic blocks (recent posts, testimonials, team), should this instance pull the latest 3, posts in a specific category, related posts based on the current page, or a hand-picked list? We define the available source modes when we build the block. The editor picks one when they drop the block into a page.
Instance variant
Layout variations of the same block
A testimonial block might have three layouts: a single close-up quote, a side-by-side pair, or a three-up grid. Same data, different presentation. The editor picks the variant on a page-by-page basis. We pre-build each variant and QA it once, so all three are guaranteed to look right.
Brand tokens
Approved colors, fonts, and spacing
Background color picker scoped to the four brand colors, not a free-form hex input. Heading style picker limited to your approved type scale, not arbitrary font sizes. The brand stays consistent because the controls are scoped to brand-safe options, not unbounded.
Semantic structure
Heading level and SEO tags
Should this section's heading render as an H2 or an H3? Should this card have a structured-data badge for search engines? These are decisions that affect SEO and accessibility, so we expose them as deliberate editor controls rather than letting them default by accident.
Visibility rules
When and where the block appears
A block can be set to show on desktop only, hide on mobile, appear only between two dates, or appear only when a flag is set. Useful for promotional banners, seasonal CTAs, or audience-specific content without rebuilding the whole page.
CTA bindings
What buttons link to and how
For any block with a button, the editor picks internal page, external URL, email, phone, or scroll anchor. The styles (primary, ghost, link) are pre-defined - the destination is yours to set per instance.
This granularity work is the nitty-gritty of the build. Every block is a small system of decisions: what stays fixed, what flexes, and which constraints protect the brand. We surface these decisions during discovery so you are not finding out about them after launch.
The balance question
Most marketing sites land at 20 to 30 reusable blocks. The first ten or fifteen pages of a site usually define eighty percent of them - hero, feature grid, testimonial, FAQ, CTA, the obvious essentials. After that, every additional page is mostly recombining what already exists rather than inventing new patterns.
The discipline is not in adding new blocks. It is in not adding them when an existing one will do. Too few blocks and editors feel constrained. Too many blocks and the site loses visual consistency, technical debt creeps in, and your team faces decision fatigue every time they create a page.
Our job is to find that balance with you - enough blocks to give your team real flexibility, few enough that the site holds together as a single, coherent experience.
Why this upfront work matters
Visual consistency
Every page composes from the same vetted parts. The site stays on-brand a year from now without anyone policing it.
No technical debt
Clean schemas with no tacked-on fields, no plugin sprawl, no "we'll fix it later" decisions accumulating into a rebuild.
Future-proof
Content is modeled by meaning, not by how a page was first laid out. The same data can feed a redesign, a new section, or an entirely different channel.
Clean for humans and bots
Structured data is readable by your team, your search engines, and the AI tools that will increasingly read your site on a visitor's behalf.
What your team handles without us.
Routine edits run through Sanity Studio. Form fields, drop-downs, drag-to-reorder. Save, and the site rebuilds in seconds.
Day-to-day edits
- Update text on any page
- Add or remove blog posts, news, research articles
- Swap photos, update alt text and captions
- Change CTAs, hours, contact info, team bios
- Schedule posts and toggle draft / published
- Reorder sections within pre-approved layouts
- Add new pages from existing templates
What still flows through us
- New section types or layouts that did not exist before
- New animations, integrations, or functionality
- Brand-level redesigns or palette changes
- Custom features (calculators, portals, integrations)
- Anything that touches accessibility, SEO, or performance
This list is the same on any platform - the difference is that here it goes through a defined workflow instead of someone improvising in a GUI.
When new patterns are needed.
If your team needs something that the existing components do not cover, here is exactly how that request travels - editor, designer, and developer each have a defined role, and you always end up back in control of the publish step.
The workflow looks heavy on paper - in practice, most edits never leave step one. New components are the exception, not the rule. Once a pattern exists in the library, it gets reused everywhere it fits.