Kirki and the Infinite Canvas: WordPress Finally Starts Thinking Like a Design Tool

Some titles sound like press releases. Others make you stop for a second. Kirki as WordPress’s first visual builder with an infinite canvas belongs to the second group. Not because WordPress needed yet another builder —we have plenty, thank you— but because the idea of an infinite canvas changes the conversation.

For years, we have designed WordPress websites as if assembling catalog furniture: columns, sections, containers, blocks, margins, responsive settings, and the eternal question of “why does this look fine on desktop and like a badly packed moving truck on mobile?”. An infinite canvas promises a different logic: thinking of a website as a visual system, not just a stack of blocks.

That is where Kirki may become interesting. Not because of the wow effect, but because of what it could mean for designers, developers, and companies that need to prototype, decide, and publish without turning every change into a three-hour meeting.

Kirki does not start from scratch, and that matters

Anyone who has worked with WordPress beyond installing pretty themes knows Kirki is not a new name. For a long time, it has been linked to theme customization and the Customizer ecosystem. In other words, we are not talking about a brand that appears out of nowhere with a spectacular video and zero technical scars.

In WordPress, that counts. A lot.

Launching a visual editor is easy if all you show is the demo. The hard part comes later: theme compatibility, performance, HTML structure, CSS that does not look like it was written during a power outage, accessibility, real responsive behavior, production loading, security, exports, migrations, and coexistence with Gutenberg. The party starts when you use it on a site with traffic, third-party plugins, and a client who clicks buttons without warning.

That is why I care more about the architecture than the promise. If Kirki manages to combine a powerful visual experience with clean technical output, then yes, we may be looking at more than “just another builder”.

The infinite canvas is not just visual decoration

The infinite canvas concept comes from tools like Figma, FigJam, Miro, and other modern product editors. It lets you move freely, create areas, explore variants, compare layouts, and build a broader view of the project.

In a traditional WordPress website, you usually work page by page. You edit the homepage. Then a landing page. Then a product page. Then a template. Each piece lives in its own drawer. It works, yes, but it does not always help you see the whole system.

An infinite canvas applied to WordPress could enable something much more useful:

  • Designing several versions of the same section without duplicating entire pages.
  • Comparing landing page structures before publishing them.
  • Visualizing complete flows: ad, landing page, form, thank-you page, email.
  • Improving collaboration between design, development, and business teams.
  • Turning prototypes into implementation without rebuilding everything from scratch.

That last point is key. Companies lose a huge amount of time between “what was approved in design” and “what actually got published”. Sometimes they look like distant cousins. If Kirki reduces that gap, it has business value, not just aesthetic appeal.

The uncomfortable question: does WordPress need another builder?

Short answer: no. Useful answer: it depends.

WordPress already has Gutenberg, patterns, reusable blocks, full site editing, established visual builders, and an endless collection of plugins that promise to do everything except make your coffee. The problem is not the number of tools. The problem is that many visual tools end up generating technical debt disguised as productivity.

I have seen websites built with builders that were “very easy to edit” at first and, two years later, had become a minefield. Embedded shortcodes, duplicated styles, impossible-to-maintain templates, absurd loading times, and clients trapped inside a tool because migrating was more expensive than rebuilding the site. Very convenient —until it stops being convenient.

So if Kirki wants to play seriously, a nice interface is not enough. It needs to answer boring questions, which are precisely the important ones:

  • What HTML does it generate?
  • How does it manage CSS and JavaScript?
  • Does it respect accessibility best practices?
  • Can it work with custom fields?
  • Does it integrate well with Gutenberg or compete against it?
  • What happens if the plugin disappears?
  • Can it be used in professional projects without fear of lock-in?

The visual experience sells. The technical output decides whether a tool survives in real projects.

What a developer checks before getting excited

When a new visual tool appears, the designer usually asks: “What can I create?”. The client asks: “How long will it take?”. The developer asks: “What is this going to break?”.

That is not pessimism. It is professional survival.

In WordPress projects for businesses, especially when WooCommerce, automation, CRM, ERP, or external integrations are involved, the builder cannot be a black box. It must coexist with data, permissions, roles, cache, SEO, translations, and maintenance. A website is not an interactive poster. It is part of the business.

From that perspective, I would like to see Kirki handle three layers well:

  • Visual layer: real freedom to design without fighting containers every five minutes.
  • Technical layer: clean, extensible code compatible with WordPress standards.
  • Business layer: the ability to create pages that convert, can be measured, and can be maintained.

If it only delivers the first one, it will be pretty. If it delivers all three, it can become a serious tool.

Gutenberg, blocks, and the eternal clash between freedom and control

Gutenberg has improved a lot. I say that without sarcasm, which is already something. Block editing has changed the way content is built in WordPress, and full site editing is slowly closing many of the CMS’s historical wounds.

But Gutenberg still has a natural tension: it wants to be flexible while remaining structured. That is good for consistency, but sometimes it falls short when you need to explore visual ideas quickly.

That is where an infinite canvas could bring something different. Not necessarily replacing Gutenberg, but acting as a more visual composition layer. The key is integration. If Kirki generates native blocks, respects patterns, and works cleanly with WordPress data, things could get interesting. If it creates its own parallel universe, we already know how that movie ends.

To better understand where WordPress is heading as a platform, it is also worth looking at recent ecosystem changes, such as those discussed in what WordPress 7.1 brings and what really matters. WordPress is moving, even if sometimes it does so at the calm speed of someone who knows half the internet depends on not breaking things.

For companies: fewer meetings, better prototypes

From a business perspective, the interesting part of Kirki is not that it lets you “design beautifully”. That should be included by default. The interesting part is whether it can shorten the cycle between idea, validation, and publication.

Think of a company that launches campaigns frequently: an academy, a real estate agency, a clinic, an online store, a B2B consultancy. Each campaign usually needs a landing page, forms, tracking, perhaps n8n automation, CRM integration, or analytics events. If every landing page depends on going through design, layout, review, development, and publication, the calendar starts to look like a bad joke.

A visual tool with an infinite canvas could help teams work differently: prototype several hypotheses, validate messaging, build variants, and publish faster. But careful: agility does not mean permanent improvisation. It means having a system that lets you move quickly without breaking everything.

In projects involving lead capture, forms, or funnels, it is also useful to review ideas like reducing no-show appointments with WordPress. In the end, a good visual interface is not worth much if it does not connect with real business processes.

For developers: not everything visual is the enemy

Some developers hear “visual builder” and start sweating CSS. I get it. We have suffered too many magical layers that promised to save work and ended up generating more tickets than a poorly integrated payment gateway.

But cheap purism is not useful either. Not everything has to be handmade to be professional. The question is not whether a tool is visual or not. The question is whether it respects the project.

A good builder should allow the developer to define limits, components, global styles, dynamic fields, and reusable structures. It should help marketing edit without calling a programmer to change a sentence, but without allowing them to turn the homepage into a medieval fair with seven typefaces and fluorescent buttons.

The trick is combining freedom with judgment. In my experience, the best WordPress projects are not the ones that give the client absolute control, nor the ones that lock everything down. They are the ones that design a flexible system with guardrails.

If you create plugins, custom fields, or more advanced architectures, it may be useful to connect this conversation with approaches like Modern Fields Pro in WordPress or more technical work such as native React in WordPress plugins with Antonella Framework. That is where you see whether a visual tool can coexist with serious development or is only useful for showcase pages.

The risk of builders: speed today, debt tomorrow

Technical debt rarely arrives with dramatic music. It arrives with phrases like “we will do this quickly and clean it up later”. Spoiler: later almost never comes.

That happens a lot with visual builders. You launch quickly, change quickly, improvise quickly. Everything is fast. Until the site becomes too heavy, the structure is impossible to understand, SEO suffers, the editor slows down, or nobody knows which template controls which part.

That is why, before adopting Kirki in a real project, I would check this:

  • How it behaves with cache and optimization.
  • Whether it allows versioning configurations or exporting designs.
  • How dependent the content becomes on the tool.
  • How it affects Core Web Vitals.
  • Whether it preserves proper semantic structure.
  • How it responds on mobile and intermediate screen sizes.
  • What learning curve it has for a non-technical team.

It is also worth keeping a general site health checklist nearby. Articles like why your WordPress site is losing traffic are useful reminders of something basic: the editor is only one part of the system.

A visual tool is not dangerous because it is visual. It is dangerous when it hides technical decisions someone will have to pay for later.

What I would like to see in Kirki

If Kirki wants to stand out, it does not need to win by quantity of effects. It needs to win by judgment. Personally, I would like to see:

  • Deep integration with native blocks.
  • Clear global style management.
  • Reusable components without absurd duplication.
  • Support for dynamic content and custom fields.
  • Clean and accessible HTML output.
  • Good performance without relying on twenty external optimizers.
  • Real compatibility with professional workflows.

And, while we are asking, decent documentation. It sounds minor until you are trying to understand at eleven at night why a template does not inherit styles and the documentation says “just click save”. Wonderful. Thanks for nothing.

Conclusion: the infinite canvas only matters if it does not lock us in

Kirki has a strong promise: bringing WordPress toward a more visual, open, and flexible way of building pages. The infinite canvas concept fits very well with how many teams work today: exploring, comparing, iterating, and turning ideas into publishable assets.

But the promise is not enough. WordPress does not need more magic. It needs tools that respect content, performance, maintainability, and the freedom to leave if you change your mind tomorrow.

If Kirki achieves that, it could be important. If not, it will be another good-looking builder for demos and a complicated one for production. And we already have a generous collection of those.

The good news is that the direction is interesting. WordPress needs more tools that think like designers without forgetting that underneath there is code, business, and maintenance. Because in the end, a website is not judged by how good it looks in the demo, but by how it holds up six months later, when there are campaigns, changes, deadlines, plugins, clients, and reality. Especially reality.

you can see more in https://kirki.com/

We Build Digital Presence That Converts

Most agencies deliver pretty. We deliver results. Whether you need a high-performance website, a brand identity that commands attention, or custom development that actually works — we’ve got the team and the track record. Remote-first, globally available, zero excuses.

Previous Post
Boost Your Sales Prospecting with Dolibarr CRM Without Drowning in Spreadsheets
ARTÍCULOS RELACIONADOS
Is your WordPress site costing you clients?

Slow performance, errors, and downtime destroy trust and conversions.

We keep your website optimized, secure, and always running at peak performance—so you never lose opportunities.

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.
You need to agree with the terms to proceed

Skip to content