A content change should not become a redevelopment project.
A client needs to change a sentence, update an image, or fix a link. The site may be perfectly good, but its source lives in an export or application that does not give that client an approachable editing experience. Replacing the entire website just to improve editing creates a different, larger problem.
I built Okeike to add an editing layer to the sites I already maintain. A shared editor, a site registry, recoverable drafts, and a versioned publication path bring those different websites into a consistent working experience.
The preview becomes a place to work.
The React editor combines authentication, site and page navigation, previews, and focused controls for text, images, and links. A central registry describes each site's source layout and asset paths. Drafts are stored and can be restored, so a session does not have to start over because a browser was closed.
AI assistance can propose edits using the selected site's context. The result is a draft patch plan for the current page, which the user can inspect and apply. Static HTML pages and structured application content follow different patching paths instead of being forced through one indiscriminate rewrite.
Keep the scope of the change visible.
The patching layer works with constrained selectors and structured fields. Source-version fingerprints and base-file identifiers help the workflow recognize when the file behind a draft has changed. Those controls matter in a multi-site editor: the correct paragraph on the correct version of the correct site is the unit of work.
Publishing creates a GitHub commit and follows the existing deployment pipeline to the relevant Firebase Hosting target. That preserves a record of what changed and a practical route back through version history. The editor works with the delivery system the sites already use.
An editing workflow that respects the original build.
Okeike brings together inline editing, reusable site configuration, draft recovery, AI-proposed changes, and versioned publishing. The product's most important shift is making a small content update a bounded, reviewable action rather than a request to regenerate the page.
The next stage is refining the client-facing workflow and expanding reliable coverage across the maintained sites. The useful foundation is already there: make a focused edit, see its effect, and publish it through the same delivery path as the rest of the site.
About this case study +
Current Okeike README, site-registry audit, editor page and AI dock implementation, patching backend, and publication architecture in the LT repository.
Researched and updated October 3, 2026.