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. In controlled beta, with a documented real-site pilot and hosted editor demonstration.
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 fix editing by putting back the database and the plugin surface the static site existed to avoid.
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 publish approved content changes to the hosting destination configured by the operator. They cannot access other sites or change that destination; published sites remain plain static files.
04
Content changes are versioned with rollback. Backups are integrity-verified bundles that can be 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 June 2026 pilot used a real trilingual school website: pages were ingested, structure locked, and forbidden edits rejected. That establishes the editing and export workflow; each client handoff is assessed separately.
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.
The client reviews the validated change and publishes their own site; 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 public sandbox of the real editor on a fictional bakery site. The sign-in is prefilled, just press Sign in, change a headline, try to break the layout (you can't), and roll back. Resets every 30 minutes. Hosted on a free tier, so the first load can take up to a minute to wake.
Open the sandbox ↗
A faithful reconstruction of the verified local editor state. Client identities, URLs, credentials, and production account details are excluded.
The actual editor on the live, named Alaska ATV Rentals site (shown with the client's written permission): locked structural chrome, editable content fields, a live preview, and saved version history, all real. The editable phone-number field and disabled AI-assistant input are redacted; the same approved public number remains visible in the locked site header, which clients cannot modify. No credentials or account identities are shown.
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, site-scoped client 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.
A fresh client-use review is pending. The dated pilot and hosted-beta evidence below describe what was checked; they do not establish a current count of active client sites.
A separate demo instance now lets anyone try the real editor on a fictional business (Bright Bakery): the sign-in is prefilled, edits render live, structure-breaking attempts are rejected by the Guardian, rollback works, and the sandbox resets itself every 30 minutes. Deploys and pushes are disabled in the sandbox; it runs apart from the production instance.
The next milestone: enough real editing history to describe client experience and reliability under sustained use, then onboarding further sites as the workflow stays stable.
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 real-site pilot demonstrated the editing workflow.
The June 10, 2026 pilot exercised ingestion, locked structure, rejected edits and a static export. Sustained client-use outcomes are still being documented.
The safety model holds under real content.
Pilot: structural chrome stays locked, forbidden edits are rejected with correct reasons, and exports contain no internal data.
Describe your setup in a few sentences. You'll get a plain answer about whether and how I can help.
