How the CMS Works
What staff can edit, how sections work, and when to involve a developer
Philosophy
The finished site will be editable by your team for day-to-day needs. The goal isn't to limit control — it's to make editing safer, clearer, and easier.
Why Payload instead of WordPress
The reasons that matter for editors: content in Payload is structured, so pages are assembled from the same section types the design system defines. What you edit maps one-to-one to what visitors see, with live preview as you work. There's no page builder to fight and no plugin stack to babysit; the forms, sliders, and popups that are separate plugins on the current site are just features here. And because the editor can only produce layouts the design system allows, it's hard to accidentally break a page.
The broader reasoning (performance, security, SEO, hosting) is covered under Platform & Technology.
What staff can do
Edit content
Headlines, body text, links, images, and media on any page
Manage sections
Add, remove, and reorder predefined sections within a page
Update CTAs
Change calls to action, button text, and button destinations
Create pages
Build new pages using existing layouts without developer help
This covers the vast majority of real-world content changes.
How sections work
Pages are built from a growing library of reusable section types. The most common ones:
- Text blocks
- Image + text combinations
- Call-to-action sections
- Statistics / impact metrics
- Embeds (donation forms, maps)
- Card grids (services, team, FAQs)
- Testimonials
What this means in practice
- Add sections to pages
- Choose which sections appear and in what order
- Adjust the content inside each section freely
- Create new pages from existing section types
- Keeps layouts consistent and clean across pages
- Handles the structural accessibility work (semantic markup, keyboard support, contrast-checked components) so editors only need to mind content-level things like alt text and link wording
- New pages match the rest of the site without extra effort
When to involve a developer
For larger changes like:
- New section types
- New page templates
- Structural changes to navigation
This matches how things already work: your team handles content updates, and bigger changes happen collaboratively.
Content update expectations
| Aspect | Expectation |
|---|---|
| Update frequency | Occasional, not frequent |
| News & Events | Posts and events as the team has them — no required cadence |
| Landing pages | Staff can create as needed |
| Section reordering | Supported within pages |
| Content additions | Supported without developer help |
The site should work well even if content changes infrequently. It's designed for stability, not constant publishing.