A CMS that a model can write to without breaking the sit…
{{ post.deck }}
{{ sec.h }}
{{ para }}
- {{ li }}
{{ sec.quote }}
The market need
A small business can now describe a website and get one. What it cannot get, from most of these tools, is a way to change the third paragraph of the services page next March without regenerating the whole thing and losing the edits it made in between.
That gap is the reason so many AI-built sites are abandoned within a quarter. The build was free; the maintenance was impossible. GoLively exists because the interesting problem starts after the site is live.
Generate into a schema, never into markup
The rule that made everything else tractable: the model never emits HTML. It emits content that fits a typed schema — a hero has an eyebrow, a headline of at most sixty characters, a subhead, and an optional call to action — and the renderer turns that into markup.
This sounds like a limitation and functions as a safety net. A model that returns a headline of two hundred characters fails validation and retries; it cannot silently produce a page whose layout collapses on a phone. It also means a human editing that headline later is editing a field, not a div.
Every generated field carries provenance
Each value stores who wrote it and when: model, human, or model-then-edited. That single flag drives most of the useful behaviour in the product.
Regeneration never overwrites a field a human has touched.
Review queues can show only what the model changed since the last approval.
A page can report honestly how much of it has been read by a person.
Review is not optional, so make it fast
Teams that try to eliminate review end up with a site nobody trusts. Teams that make review a diff — old value, new value, accept or reject, keyboard shortcuts — get through a fifty-page regeneration in twenty minutes and keep using the tool.
The failure mode we watch for is approval fatigue: if the diff is noisy, people start accepting everything, and the review becomes theatre. Grouping changes by intent rather than by field is what keeps it honest.
Treat generated copy exactly like a pull request from a fast, confident, occasionally wrong junior colleague.
The CRM was not a feature, it was the point
Owners do not want a website. They want the enquiries a website produces, in one place, with a record of what was said. Putting the CRM in the same system as the pages means a form field, the page it sits on, and the lead it created share one schema — and the site can be improved on the basis of what actually converts rather than what looks good.