Why we don't have a drag-and-drop editor

We get asked this in most first conversations, usually politely, in the tone of someone checking whether we know it's missing. We do. It's a decision, and this post is the argument for it rather than an apology.

What a canvas actually produces

A visual canvas editor lets you position things: a two-column row here, thirty pixels of space there, this image at that width on desktop and a different width on a tablet. The output is a description of an arrangement.

That description is only meaningful to the editor that produced it. It isn't content in any portable sense — it's a layout, expressed in one tool's private vocabulary. Which is fine if that tool renders your site forever. It stops being fine the moment anything else needs to read your content: a second site, a native app, a screen in a shop, a search index, a language model answering a question about the business.

The three things it costs

Portability. Content stored as a layout can only be rendered as that layout. Ask "can we reuse these case studies on the new microsite" and the answer involves copy-paste.

Consistency. A canvas gives every page its own spacing, its own type sizes, its own margins. Not because anyone decided to — because the tool makes each of those a free choice on every page, and free choices drift. A site built on a canvas over two years is a site with forty slightly different heading sizes.

The handover. This is the one that costs agencies money. A canvas hands the client both content control and design control in the same gesture, so the client who wanted to add a case study also gets to reflow the grid. We've written about that at length elsewhere; it's the same argument from a different side.

What we do instead

A page is an ordered list of blocks. Each block is an instance of a section type you defined — a hero, a feature grid, a testimonial set, a form. The editor lets you add, remove and reorder blocks, and fill in each block's fields. That's it.

The page is stored as structured data: which sections, in what order, with what content. Not pixels, not columns, not breakpoints.

Then the front end renders it. The theme owns how a hero looks, how it behaves at 375 pixels wide, what the spacing scale is. Composing the page is a content job. Rendering it is a design job. The two are done by different people, at different times, with different tools, and nothing crosses over.

What this is good for

Every page is consistent by construction, because every hero is the same hero. A redesign is a theme change rather than a migration — the content doesn't move. The same blocks can be rendered anywhere, including by things that aren't browsers. And a client adding their eleventh case study cannot produce a page that looks wrong, because the arrangement isn't theirs to choose.

It's also why an agent can build a site here. An ordered list of typed sections is something a program can read and write correctly. A canvas layout isn't, really — it can be generated, but it can't be reasoned about.

What it costs, honestly

Someone has to define the sections before a client can use them, and that someone is you. If the client wants a kind of section that doesn't exist, they can't invent it; they come back to you, and that's a small piece of billable work rather than something they do at midnight.

It's also worse for your own site, where you genuinely want both kinds of control and there's no handover to protect. We use a hand-built site for our own marketing pages, which tells you something honest about where the line is.

And it's slower for the very first page. Dragging a hero onto a canvas beats defining a hero type. By the tenth client site it's the other way round, because the definitions are reusable and the canvas arrangements never were.

Where we're going instead

The real complaint behind "there's no drag-and-drop" is usually not about dragging. It's about not being able to see what you're editing. That's fair, and the answer we want is live preview with click-to-edit: click an element in a preview of the real site and land on the field that produces it, in the block editor that already exists. Same model, same constraints, much better feedback. That's the direction — not a canvas.

The short version

A canvas optimises for the person building the page today. Structured composition optimises for everyone who touches the content afterwards. We build for agencies who hand sites over, so we optimise for afterwards.