A custom website should have a clear answer to a simple question: what can your team change without a developer? That answer belongs in the scope before the site is built. It should describe real tasks, not just name a CMS.
Start with the people who will maintain the content. A founder making occasional changes needs a different setup from an editorial team publishing every week. Neither needs every design control exposed by default.
Start with your editing tasks
| Your task | What to agree before the build |
|---|---|
| Change text, images or links | Which fields are editable, image requirements and how changes are previewed. |
| Publish a story or project | The content fields, reusable layout, draft workflow and who can publish. |
| Add a page | Whether editors can use approved page types, and when a new layout needs design and development. |
| Change navigation or structure | Who can make the change and check its effect on existing pages and links. |
| Add a feature or integration | The person responsible for scoping, building and testing the change. |
Choose the editing method around the work
A standard CMS is often a good fit for structured content such as stories, projects and team profiles. Editors work in defined fields and the website presents the result through reusable layouts. It is useful when content grows regularly or several people need to manage it.
An inline editor can suit smaller, controlled changes. When included in the project, it can let an editor update selected content in the context of the page. The scope must still say which fields are editable, how publishing works and what recovery is available.
Some technical teams prefer a code-based workflow. That can support broader changes, but it also requires review, testing and someone responsible for releasing them. It should be a deliberate choice by a capable team, not a prerequisite for changing a headline.
See a real task before you approve the setup
Ask to walk through a change your team will actually make: replace a project image, save a draft and publish it. Check the mobile result as well as the editor. A feature list cannot show whether the workflow makes sense to the person using it.
- Who can edit, review and publish?
- Can the team preview a change before visitors see it?
- What happens if an image has the wrong shape or a title is longer than expected?
- How are previous versions or backups recovered, where that capability is included?
- Which changes need developer support, and how is that work requested?
Agree the handover and support
At Displace, the editing method is chosen around the project. The written scope should name the content types, editable areas, roles and training included. New layouts, integrations or functionality may need additional work even when routine content edits are available to your team.
Ongoing care starts from $2,250 per month and is scoped separately. If you want us to publish content or make regular page changes, include those tasks in that conversation. An editing tool and an ongoing publishing service are different deliverables.
The right test is whether the person responsible for content can complete their recurring tasks confidently, with a clear route for everything else.