The Safe-Editing CMS lets a business update its approved content — text, images, links — while the site's structure stays locked. Every change is validated before it can apply. Currently in controlled beta with one real client site.
The business
Static websites are the fastest and most secure thing a small business can run — but the moment the owner needs to change prices, hours, or photos, they're either waiting on a developer or handed a page builder with enough rope to break the layout. Traditional CMS platforms solve editing by giving up the speed, security, and simplicity that made the static site worth having.
The real problem
Let a non-technical client edit their own content safely — without being able to break the design, take the site down, delete the wrong thing, or get the business hacked through a plugin. And let the operator hand a site over without becoming a permanent helpdesk for every text change.
My responsibility
The whole system: the editing model, the validation layer, the hosted dashboard, the publishing pipeline, backups and recovery, and the operational rules for running it on behalf of clients.
What was built
01
When a site is taken on, its layout — navigation, footer, branding, critical buttons — is frozen as structural 'chrome'. Only approved content slots (specific texts, images, links) are editable. A client can change the words; they cannot move, delete, or restyle the page.
02
A deterministic validation layer — not an AI, not a setting — is the only path a change can take. Edits that would inject scripts, empty out required text, or point links somewhere unsafe are rejected with a plain reason. The same rules apply to everyone, including the operator.
03
Clients log in through a private link scoped to their own site — they can't see other sites and can't publish. The operator reviews and publishes; published sites deploy as plain static files to their own hosting.
04
Content changes are versioned with rollback. Backups are integrity-verified bundles stored off the host, and restore only accepts bundles that pass verification. An append-only audit history records what changed, when, and by whom.
05
The system was validated end-to-end on a real trilingual school website: all pages ingested, structure locked (112 editable vs 55 locked slots per page), forbidden edits rejected with the right reasons, and the exported site deployed and verified on an isolated pilot project — without touching the client's live site.
System view
Through a private, site-scoped login: text, image, or link in an approved content slot.
Deterministic checks accept the change or reject it with a plain-language reason. Structure is untouchable either way.
Versioned change is reviewed; publishing exports the full site as static files.
The static build goes to the site's own hosting. The live site never depends on the CMS being up.
Inspectable proof
Sanitized artifacts show the underlying work without exposing client identities, credentials, private dashboards, or customer data.
A faithful reconstruction of the verified local editor state. Client identities, URLs, credentials, and production account details are excluded.
The product checks were rerun before publishing these proof numbers.
Evidence
Completed and passed: configuration security, error handling, backup safety, and route-validation audits.
Completed and passed: full local publishing and recovery rehearsal — production checks, integrity scan, backup, dry-run restore, and edit-rejection behavior.
Completed: the dashboard runs as a hosted service with persistent storage; owner login, site-scoped client access, owner-only publishing, off-host backups, and per-site deploy targets verified.
Trilingual client site ingested, chrome locked, locked-slot edits rejected, full export deployed to an isolated pilot project and live-verified.
The next milestone: a real client using the editor on their own site, with observations driving what changes next.
Results & current state
The complete editing-to-publishing loop exists and has been exercised end-to-end.
Milestone records: hardening, operator rehearsal, hosted beta, and a real-site pilot all completed and passed.
The safety model holds under real content.
Pilot record: structural chrome stayed locked, forbidden edits were rejected with correct reasons, and exports contained no internal data.
Describe your setup in a few sentences — you'll get a plain answer about whether and how I can help.