Idea log

Chronological capture of important idea evolution. Entries record thinking; they are not automatically decisions.

2026-08-22 — Initial concept

• Create a “better WordPress” experience as a plugin or plugin-based system.
• Reject the premise that clients should assemble and redesign entire sites block by block.
• Restore separation between content and design.
• Use purpose-driven blocks or modules whose HTML meaning is distinct from their CSS presentation.
• Let the developer provide approved designs and selectively expose safe controls.
• Edit the actual front end with visible bounding boxes and persistent controls.
• Support inline text changes, clear movement, duplication, deletion, insertion, and deliberate module settings.
• Preview a design variation in context before applying it.
• Hide WordPress implementation vocabulary such as blocks, reusable blocks, synced patterns, and template parts when it does not help the user’s task.
• Preserve semantics, accessibility, responsiveness, branding, and performance through professional constraints.

2026-08-22 — Feasibility framing

• The product is best understood as a safe, purpose-driven editing layer for WordPress.
• It should keep WordPress as the storage, permission, media, revision, and rendering engine.
• A front-end overlay on the normally rendered WordPress site is a better first architecture than headless WordPress.
• A plugin is feasible if WPS explicitly supports a curated module ecosystem rather than claiming universal compatibility.
• Content entities, page modules, and design variants should be separate concepts.
• Autosaved work should not become public on every keystroke; publication remains deliberate and revisioned.

2026-08-22 — Agency platform expansion

• The creator is also the target buyer: an experienced agency or developer who wants a complete production system for client sites.
• WPS could grow from a WordPress plugin into an entire SaaS offering for agencies and developers.
• The analogy is not a generic plugin marketplace but an opinionated professional foundation—similar in spirit to how developer ecosystems such as Genesis once offered a shared way to build sites.
• Working name: WebProduction Studio (WPS).
• WPS could provide robust developer documentation explaining how to create modules, design systems, and complete sites from scratch.
• The system could make client satisfaction a product outcome: clients understand their sites, are less afraid of updates, and need less support.
• An LLM agent could connect to WPS and create websites using the project’s documented modules, constraints, and design system.
• The valuable agent experience is constrained and structured—not arbitrary AI-generated pages.
• The idea creates two reinforcing experiences:
• Agencies build faster and encode their standards.
• Clients receive a much better editing and handoff experience.

2026-08-22 — Public home and open/hosted model

• The webproduction.studio domain was unexpectedly available and was purchased.
• The public site should be a polished, dark, glassy, contemporary landing page that can attract WordPress developers and potential collaborators.
• The site should be driven by the living product documentation so published thinking stays current and transparent.
• Public information about the plugin, module system, architecture, roadmap, and independent development should remain distinct from future authenticated WPS functionality.
• The long-term site can become the WPS web application and be deployed on modern app infrastructure.
• The ecosystem model should give people the documentation and tools to build independently while offering a paid managed system for teams that want the complete production environment.