The site is live and one number is wrong
The bakery on the corner opened on Tuesday, and the website still says nine. In fact they open at eight, and for a week customers have been phoning to ask why the door was shut. Changing that line of text takes a minute for somebody who can edit the site. It takes a ticket, an invoice and three days for somebody who cannot.
Most small businesses find out which of the two they are in the week after launch, while a customer is reading the wrong number. The pages, the layout and the forms are all fine. The problem is one figure that should have been the easiest thing on the site to change.
Why a generated site arrives hard to edit
A generator produces output, not an editing surface. It writes pages, and the text lives inside those pages: the price sits in the markup, the opening hours sit inside a component, the service list sits wherever a person who only reads websites would never look. None of that is broken. It simply was not designed for someone who will change it twice a month.
Most of the time nobody chose this — the build simply started. The tool emits a form of output because that is what it emits, and the question of who edits the site later was never asked. An unasked question receives the default answer: whoever wrote the code edits the code. By the time somebody wonders how to publish a news item, the answer is already a developer’s calendar.
The opposite arrangement has its own trap: content that lives inside the tool. Editing is genuinely easy there — a field, a button, a saved page — until the subscription ends, the account belongs to a former employee, or the platform changes what it exports. Being easy to edit and being yours to take are two different properties, and a generated site can lose either one without looking any different.
Three editing models, and they have to be picked before the build
You are choosing one of three, whether or not anybody says so out loud. Edit inside the builder: the fastest route to a corrected price, with the site, its content and your ability to change both held inside one product. Edit through a content layer, where text and structure sit apart from the design so that a person can change a price without meeting the layout: this takes setup that belongs in the build, because you cannot pour an editing system into an exported site afterwards without rebuilding it.
Edit the code: complete control, and every change becomes a task for a developer.
The third model is what happens when nobody picked one. It is correct for a page nobody will touch for a year and wrong for a price that moves every season. Most businesses only discover which model they received when they try to publish something on a Friday afternoon.
None of the three is free. The builder trades away independence, the content layer costs setup time, and the developer route costs attention every time something changes. Paying the price knowingly is the whole point; the expensive case is paying it by surprise.
Who needs to change what
Write this as a list of tasks before you write it as a list of logins. In a normal month: a price changes, an opening hour changes, a service is added, a date sells out, two articles go up, a photograph of the team is replaced. Now attach a person to each line. The pattern is dull and almost universal — the owner updates facts every week, somebody writes content now and then, and only a developer should be touching layout or structure at all.
That map turns into permissions, and permissions are the thinnest part of a generated site. One shared login handed around by email, three people editing the same page in the same hour, and nobody able to say who changed the number last. Give each person their own account with the smallest set of rights that lets them do their job, and make removing somebody a one-minute action, because people leave and passwords passed around in messages do not expire.
The rule we build with: anything that changes weekly must be editable by someone who is not a developer, without the ability to break the page. If changing a price can also delete the layout, the price will not be changed. That is how a restaurant ends up with a menu from last spring on a site that looks brand new.
What AI is genuinely good at in this decision
Use it to answer the first question quickly: what on this site will change, and how often. Hand the tool the pages or the built output and ask it to list every value that will move — prices, hours, dates, availability, contacts, people — and roughly how often the business touches each one. It will also draft the editing guide for whoever maintains the site, the list of fields they should see, and the test nobody writes by hand: give a real person a real task and watch where they get stuck.
It cannot decide who in the business should hold access, or how much freedom they get. That depends on who is careful, who is still with the company in two years, and how far the site is expected to grow — judgements that live inside the business, not inside the build. They are also the answers that are most expensive to change later, which is exactly why they belong on paper before the first page is generated.
Editing is a build decision, not a favour afterwards
The test is small and cheap: before you accept the site, ask somebody from the business to change one real number on it. Not the developer, not the person who built it. If they can do it in five minutes, find out where everything else lives and who holds the keys to it. If they cannot, you have learned something that no amount of fixing later will change, because the editing model is the part of a website that cannot be bolted on afterwards — it either exists from the first day or every future change runs through somebody else’s diary.
The pages can be generated in an afternoon; the ability to keep them true is decided before that afternoon starts, and it is worth asking for out loud.
Related service: Website and web application development