
How Clients Edit a Custom Displace Website
Two editing options for custom websites: an inline editor with guardrails, or a guided code workflow for technical teams.
Why We Moved Beyond Webflow
Webflow was our default for years: fast to build, clients could edit, the best CMS in no code. We shipped a long line of projects on it and kept hitting the same wall: design constraints, performance ceilings, integration friction, per seat pricing that punishes growth, and a content model that cracks the moment a client wants real structure.
Then the math changed. AI-assisted development made custom builds faster, and an inline editing pattern gave some clients control without a traditional admin panel. Today we choose the stack and editing method around the project. Some clients get an inline editor, some use a guided code workflow, and some need a standard CMS.
Two Editing Options We Use
Side by side
Option A: Inline CMS
Option B: Cursor Workflow
Option A: Inline CMS with Boundary Conditions
When this option is included, the client logs in and edits approved content on the live site. Text becomes a field, images open a picker and links become inputs. The editing surface stays simple because the design rules remain locked.
The important part is what it refuses to do. Every editable field is typed, constrained and validated against the design system: you cannot break the grid, drift off palette, or ship a hero image at the wrong ratio. Editing freedom inside hard walls.
- Double click any text, image or link to edit in place
- Changes preview live before publishing
- Boundary conditions prevent layout and brand drift
- Versioned content: one click rollback
- One shared component library across all pages
- No separate admin UI to learn or maintain
Option B: Cursor with Boundary Prompts
For technical teams we configure Cursor or Claude Code with boundary prompts: guardrail files that name the design tokens, the components to reuse, and the things that must never change. 'Add a blog post about our latest certification' lands in the same file structure, the same patterns and the same typography as the rest of the site. No drift.
This is how we maintain the Displace site. We only hand this workflow over when the client team is comfortable working with code and the responsibility is clear.
# CLAUDE.md for <client> ## Design system - Only use tokens from tailwind.config.ts - Primary accent: #f3350c - Never use rounded-full except for avatars - All cards: 6px radius + hairline border ## Components - Hero variants live in components/hero/* - Reuse ProjectCard for any project tile - Blog posts: use ArticleBlocks renderer ## Guardrails - Never add new tailwind colors - Never inline styles - Never create new fonts - Always run typecheck before suggesting commit
Optional Workflows After Launch
When useful, we can configure workflows for recurring jobs such as publishing, reporting or image preparation. The exact list belongs in the project scope. It is not a default promise attached to every website.
- Content Publisher: posts and announcements, schema and sitemap handled
- Page Builder: new pages inside the design system
- SEO Optimizer: meta, structured data and internal links, fed by Search Console
- Analytics Reporter: GA4 and Search Console in a weekly format
- Impact Study Creator: case studies from a structured input
- Product Page Updater: new features without touching layout
- Image Optimizer: web ready batches, Core Web Vitals safe
- Deploy and Monitor: preview, ship and verify with one command
By the numbers
8
Workflow examples
2
Editing options
Client
Code ownership
Scoped
Post-launch support
Support After Launch
After launch, we train the team on the agreed editing method and stay available through ongoing care when useful. Ongoing care starts at $2,250 per month and is scoped separately. There is no automatic twelve-week program attached to every build.
Want to see both modes on a real project? Book a 30 minute call and we will walk you through a live demo.
