Project

Okeike
Web Editor for Static Sites

A concept write-up for a WYSIWYG editing workflow that preserves structure, drafts, and publish discipline.

Overview

I designed Okeike as a concept for making static sites easier to update without turning them into unstructured CMS sprawl. Static sites are fast, stable, and inexpensive to host, but they can be painful for non-technical teams to edit.

My goal was to add a controlled editing layer: drafts, structured sections, review, publishing, and accountability.

The problem

If every content change requires a developer to open files, edit HTML, and redeploy, teams either stop updating the site or start making inconsistent side-channel changes. That becomes especially painful for SEO work, where small content updates matter over time.

I designed Okeike around the edits that matter most: copy updates, image swaps, structured sections, and controlled publishing.

Proposed architecture

I would build the editor around authenticated access and clear roles so drafting and publishing are accountable. Drafts should live as structured data rather than raw HTML blobs so the system can validate content before it reaches the live site.

Publishing should be explicit and auditable. I want the output to remain predictable, versionable, and easy to roll back instead of bypassing the discipline that makes static sites reliable.

Why it pairs with SEO work

SEO improvements often require ongoing edits: titles, internal links, service copy, location pages, and structured content. Okeike is the kind of tool I would use to make those updates easier while preserving the performance and platform control of static hosting.