An AI builds a good website in a short time today. What it does not deliver with it is a way for your client to change the opening hours afterwards. There are four solutions. They differ in who has the work and what can go wrong.
1. The client writes to you, and you change it
The simplest solution. The client sends an email, you open the project, let the AI make the change and publish again. For a website with two changes a year that is reasonable. With ten client websites it becomes an inbox full of small things, each waiting for you.
2. Content in files, with a Git based CMS
The texts move out of the HTML into files, usually Markdown or JSON. A CMS such as Decap, Sveltia or TinaCMS puts an interface on top. The client signs in, changes a field, and the CMS writes the change into the Git repository. Then the host builds the website again.
It costs little, and everything stays in the repository. But it requires that the website is built with a generator such as Astro, Hugo or Eleventy that reads these files. Hand written HTML does not fit. You also set up the sign in for the client, and you describe the fields of the interface yourself in a configuration file.
3. A headless CMS
The content lives with a service such as Sanity, Contentful or Storyblok. The website fetches it through an API, at build time or on every request. The client gets a mature interface with roles and history.
In return you look after two systems: the CMS and the website that has to match it. You create the data model, you build the connection, and hosting comes separately. For a practice website of five pages that is a lot.
4. A platform where the AI builds and the client maintains
The website is created from the start in the system in which it is later maintained. This is how Cleverpage is built. Claude Code connects to your account and builds the website from components. Each component has fields of a fixed type: a text, an image, a list of dates. The editor arises from these fields by itself, and nobody configures it.
After signing in, your client sees every page as it looks on the website and changes texts and images right there. Colours, fonts and spacing are out of reach. Whatever repeats, such as news, dates or job postings, lives in collections. Who may only change and who may publish is set through roles.
If the client wants something the components do not offer, the wish reaches you, and Claude Code builds it later.
The four ways compared
| Who changes | Work at the start | Work in operation | Can the client damage the layout? | |
|---|---|---|---|---|
| You change it | you | none | every change | no |
| Git based CMS | client | generator, sign in, configuration | little | depends on the configuration |
| Headless CMS | client | data model, connection, hosting | two systems | depends on the data model |
| Cleverpage | client | Claude builds in the platform | change requests | no |
The questions that decide
- How often does something change? With two changes a year, way 1 is enough.
- How technical is the client? Someone who can handle Git gets along well with way 2. Most clients cannot.
- Who looks after the website in two years? A setup only you understand is then a risk for the client and a burden for you.
- How many websites do you look after? With one, any setup is bearable. With twenty, what counts is that all of them work the same way.
Cleverpage is made for the last case: many client websites that an AI builds and the client maintains. For an online shop or an application with its own server code it is the wrong tool.