Having a website built that you can manage yourself: what should you agree on?

A new website only becomes genuinely useful when it keeps working for the business after handover. Opening hours change, a new service is added, a photo needs replacing or a customer asks a question the website does not yet answer. If every adjustment turns into a technical project, the business can quickly become dependent on its developer.

The short answer: agree before development starts what information you need to edit yourself, who owns the accounts and domain, how maintenance will work and what exactly will be handed over. Good website management begins with design and development decisions, not a manual delivered at the end.

Managing your website does not mean writing code

A business owner should not need to program anything to correct a sentence or add a service. Yet not every part of a website should be freely editable without safeguards. A new landing page may be handled through a content management system, while a complicated payment or booking integration will probably require technical support.

Make the difference clear. Which changes are likely every month? Which happen only occasionally? And which should only be made by someone with the right technical knowledge? That allows the website to be designed around real management tasks rather than an arbitrary list of CMS features.

The goal is not unlimited freedom over every detail. It is to give the right people safe, straightforward control over the parts they actually need to maintain.

Define the content that regularly changes

Start by listing the important content types: services, prices, staff, projects, frequently asked questions, articles or products. For each type, identify the fields required and who will update them.

A service, for example, might have a title, short introduction, full description, image, practical terms and an appropriate contact option. That structure keeps pages consistent. The business owner does not need to rebuild the layout every time something changes.

Consider exceptions too. Can a service be temporarily hidden? What happens if a price is not yet confirmed? Is a button mandatory or optional? A good content model avoids forcing someone to add meaningless filler simply to satisfy the system.

Choose a CMS for the job, not its reputation

There are different ways to manage a website. A traditional CMS often combines content editing and presentation. A headless CMS stores content separately and makes it available to the website. A simple site may need even less editing functionality.

None of those approaches is automatically best. Ask how many people will edit content, how technically confident they are, whether the site supports multiple languages and how often new pages are needed. Factor in cost, developer availability and the ability to move systems later.

A small business changing a few sentences three times a year has different requirements from a company publishing dozens of new articles and products every week. Extra flexibility has value only when people will actually use it.

Do not make the CMS more complicated than the website

A screen with twenty fields, hidden configuration options and confusing status controls does not make life easier for a busy business owner. Design the editing experience around specific tasks. Use understandable field names, prevent common mistakes and offer a preview that clearly shows what will change.

For multilingual websites, editors should be able to see which translations are still missing. Publishing Dutch content under an English URL is not a satisfactory workaround. It is better to show which language versions are complete and prevent unfinished translations from going live.

Ownership: which accounts belong to you?

Most websites depend on several services: domain registration, hosting, the CMS, analytics, email and sometimes a payment provider. If every account belongs exclusively to an external developer, a business may become vulnerable when changing suppliers.

Agree who legally and practically owns the domain, content, images and access to each service. Identify which licences can be transferred and which cannot. Where appropriate, ask for your own administrative access and use separate user accounts with suitable permissions rather than sharing passwords.

For an online shop, this goes beyond a login to the dashboard. Check who can access payment settings, orders and personal data. Do not automatically give everyone full administrator permissions. A good handover covers both access and an understandable explanation of responsibilities.

What should a professional handover include?

A list of passwords in an email is not a complete handover. At a minimum, you should understand how to edit text and images, where enquiries arrive, how to report a technical issue and which parts you should not change yourself.

A practical handover might include a short editing guide, a demonstration of the most common tasks and an agreement on technical support. Test the guide with someone who does not know the website. Can they prepare, save and verify a content change without help? If not, either the instructions or the editing interface may still be too complicated.

Also check important user journeys: contact forms, order confirmations, digital downloads, payments and booking links. A functioning homepage is not the same as a fully tested business website. Define what is covered by handover testing and which dependencies are still controlled by third parties.

Maintenance and aftercare are not the same thing

A question about changing a photo is different from a request to develop an entirely new booking feature. Agree in advance what counts as fixing delivered work, help with day-to-day use, security updates, hosting and new functionality.

Record who is responsible for each element and on what terms support is provided. Include backups, software updates, monitoring and resolving faults. Some services handle parts of that automatically, but the business still needs to check that the overall experience works.

Recurring maintenance costs are not inherently a problem. They should match the risks, usage and work involved. Ask what is included, what costs extra and what happens if you want to move to another supplier later.

Design for changes you can already predict

New website projects often focus almost entirely on the first version. But the second, third and tenth content change say just as much about quality. Choose a few realistic scenarios in advance: adding a service, replacing a photo, changing a price and publishing an article.

Ask to see how those tasks would work in the proposed editing environment. You may discover that a reusable service template matters more than an impressive animation. Or that a simple external appointment tool is a better choice than building your own system from scratch.

For many small businesses, the best website is not the one with the most features. It is the one that supports everyday work without making the team constantly dependent on a developer.

Handover checklist: ask for evidence, not just access

A handover is useful only if the right person can carry out the important tasks. Work through this checklist during the handover session and record anything still outstanding.

For online shops, test a realistic payment journey using a safe test payment or sandbox. Do not include personal or payment information in handover screenshots. A demonstration cannot guarantee error-free operation later, but it does show what is configured and what remains unresolved.

Use the list when comparing proposals: ask not only what a supplier will build, but what you will be able to manage on your own the day after launch. If you are still choosing the technical approach, see when improving an existing site may be enough and when rebuilding is worth considering.

A handover check you can use yourself

Before signing off on the final stage, ask who controls the domain, where content is edited, how backups work, which user roles exist and how to request help. Make one real content change during the handover session.

Keep a short list of anything still outstanding: perhaps a payment provider needs additional verification or an integration depends on an external supplier. Record those items explicitly so that a future owner does not assume unfinished functionality is already live and operational.

A website is not a one-off picture. It is a tool that should grow with your business. Want clear agreements about development, day-to-day management and handover from the outset? Discuss your website with Make What Works.