A lot of website tools make editing easier by hiding the source. I ended up with the opposite principle: the source is the product.

The visual editor, AI assistance, previews, templates, and deployment flow should operate on the same real project rather than creating a parallel representation that is difficult to escape.

One source of truth

A user should be able to click an element visually, change it, inspect the resulting source change, edit the same file directly, ask AI to modify it, and export the project without a conversion step.

Ownership changes product decisions

If users really own the project, export should not be a transformation. Deployment should be optional, AI should create reviewable patches, and rollback should be a first-class operation.

← Back to writing index

WebCanBe started on 17 February 2026. It moved through service, production, marketplace, and software-workspace forms rather than staying fixed to the first version.

Services exposed repetition

Web production made ownership, speed, revisions, responsive implementation, QA, and handoff visible. It also exposed repeated work between design intent and a maintainable deployed project.

The product underneath the service

By the 4 July direction change, the source-owned workspace thesis was taking shape: visual controls, code editing, AI modification, preview, export, and deployment should all operate on the same project.

← Back to writing index

Outbound forced every vague sentence about WebCanBe to become concrete. If I could not explain who the product was for, what problem it solved, and why that person should care in a short message, the positioning was probably not ready.

Specificity beats broad ambition

Creators, agencies, founders, and software teams can all make sense as audiences. The problem is that a message for everyone usually describes a category instead of a sharp pain.

Usage signals matter

Repeated imports, edits, deployments, forks, exports, and returning users are more useful evidence than superficial approval.

← Back to writing index

Visual editing gets impressive quickly in a demo. Real repositories make the problem much harder.

Classify before editing

I started designing an Environment Boundary Map and detection rules for WebCanBe: server/client boundaries, environment-variable exposure, unsupported patterns, and framework-specific constraints.

Unsupported is better than silently wrong

I would rather show that a file is preview-only or code-edit-only than offer a visual control that corrupts the project. Explicit boundaries let automation go further because users can see where confidence ends.

← Back to writing index

During one WebCanBe development phase, a repository in a cloud-synced documents location hit a dataless-file problem. The working state had to be recovered into a reliable local clone and verified.

Ownership needs a recovery path

That incident changed a product principle for me. Export is not enough. If a project is genuinely owned, its state should be reconstructable from understandable source, version history, and portable assets without depending on one editor or sync layer.

← Back to writing index