When most people see Gogh, they see a drag-and-drop page builder.
That's understandable. It's the most visible part of the project.
But if you zoom out, I think there's a much bigger story emerging.
It's not really about building another page builder.
It's about creating a bridge, and potentially, a platform.
AI Already Speaks HTML
One thing has become very clear over the last year.
AI is incredibly good at generating HTML.
Whether it's ChatGPT, Claude or Gemini, you can describe almost any interface and receive clean, responsive HTML in seconds.
The problem isn't generating the code.
The problem starts when you want to use it inside WordPress.
WordPress doesn't think in HTML.
It thinks in Gutenberg blocks.
Today, moving between those two worlds is awkward. You can paste HTML into a Custom HTML block, but you've stepped outside the editing experience. The content isn't made up of native blocks, so it doesn't behave like the rest of WordPress.
That's where Gogh comes in.
One of the most exciting things we've built isn't the canvas at all.
It's the translation layer.
AI creates HTML.
Gogh understands that HTML, lets you manipulate it visually, and then publishes it back as real Gutenberg blocks.
That feels strategically important.
As AI becomes better at generating interfaces, WordPress doesn't necessarily need to become an AI that generates layouts itself. It needs an elegant way of accepting what AI is already exceptionally good at producing.
Gogh becomes the bridge between those two worlds.
The Canvas Is Bigger Than WordPress
The second idea is even more interesting.
Today, Gogh connects to WordPress.
But if you strip away the WordPress-specific pieces, what have we actually built?
We've built a direct-manipulation canvas.
A place where people can drag, resize, rotate, reorder and arrange content visually.
WordPress is simply one backend connected to that experience.
There's nothing that says it has to be the only one.
Different products could connect that same canvas to completely different storage formats or publishing systems.
One version could save Gutenberg blocks.
Another could publish static HTML.
Another might talk to a CMS through an API.
Another could generate React components.
The editing experience stays familiar.
Only the destination changes.
A Different Way to Think About It
In many ways, the canvas starts to look less like a WordPress editor and more like a presentation layer sitting above different publishing systems.
You could think of it as a visual editing engine that happens to speak Gutenberg today.
The backend becomes interchangeable.
The editing experience stays consistent.
That's a very different way of thinking about what we're building.
Is It Pseudo-Headless?
In some respects, yes.
Traditional headless architecture separates the frontend from the backend.
Here we're separating the editing experience from the publishing target.
The canvas has its own model of the page while you work.
At publish time, it translates that model into whatever format the destination requires. Today that's native Gutenberg blocks.
It's not headless in the traditional web application sense because WordPress still owns the content and rendering. But it follows a similar architectural principle: the editing layer is decoupled from the system it ultimately publishes into.
That separation opens up interesting possibilities.
The Long-Term Opportunity
I started building Gogh because I wanted WordPress page building to feel as easy as Canva.
I still believe that's a worthwhile goal.
But the more we build, the more it feels like that was only the first chapter.
If AI continues to generate interfaces in HTML, WordPress needs a great way of turning those into native content.
And if we've built a genuinely enjoyable visual editing canvas, there's no reason to think it has to serve only one backend forever.
That's the bigger ambition.
Not simply a better page builder.
A bridge between AI and WordPress.
And perhaps, over time, a visual platform that can power many different experiences.
Leave a Reply