That might sound small. In a world of “10K MRR in 30 days” threads and Series A announcements, 100 customers in 5 months is not a headline. But I want to tell you what those 100 people actually represent, because I think the story is more interesting than the number.

I build Respira, a tool that lets AI assistants edit WordPress websites safely. Think of it this way: instead of an AI generating code and hoping it doesn’t break your site, Respira gives the AI structured access to your page builder’s native format. It can change a headline, rearrange a layout, update a product listing, and scan for accessibility issues, all without ever touching your live site until you approve the changes.

I build it alone, with Claude Code as my development partner, from Brașov, Romania. No team. No investors. No advisor board. Just me, late nights after the kids fall asleep, and an AI that writes better PHP than I do.

what 100 actually means

Some of those 100 people bought a €19/year starter license. Some bought €199 agency plans. A few stacked multiple licenses. One person asked about a 500-site plan before I even had a tier for it.

They did this when the product had rough edges. When there was a bug that wrote changes to the wrong site. When certain page layouts crashed the system. When the interface for approving changes was confusing.

3 asked for refunds. I gave every one, no questions, within hours. And then I published the bugs they found, named the fixes after their feedback, and shipped better versions because of what they told me.

One refund became my best release. A customer named Frank emailed saying the product broke his Elementor site. He was right - three specific bugs I hadn’t caught. I fixed all three, cut the amount of data the AI needed per edit by 70%, and built a smarter system for reusing work instead of starting fresh every time. Three features from one honest email.

That’s not a failure story. That’s how software should grow.

If you were one of those 100: your first name is now on a Thank You page inside the product. Small gesture, quietly listed. Your price is locked forever. Nothing changes for you.

the month everything leveled up

March was the biggest month in the product’s life. Not in revenue, in depth.

I shipped 66 new capabilities in one release. I built a dedicated intelligence layer for one specific page builder that required understanding its entire data structure, its CSS framework integration, and its concurrent editing patterns (Bricks). I launched a marketplace of 26 AI workflows that auto-sync from GitHub daily and are free for every user.

The numbers: 172 tools total, up from 106 at the start of the month. Support for 11 different WordPress page builders. Almost a million lines of code pushed through the system by real users on 448 websites.

But the thing I’m most proud of isn’t a feature. It’s the safety architecture.

Every edit the AI makes happens on a duplicate of your page. Never on the live version (unless you want that - there is a setting you can turn on). You review the changes, compare before and after, and approve or discard. If someone edits the page in WordPress while the AI is working, the system detects the conflict and fails cleanly instead of silently overwriting their work.

In a world where AI tools are racing to be faster and more autonomous, I chose to make mine slower and more careful. That turned out to be the right bet. The people who trust AI with their production websites = the ones running businesses on WordPress, serving real customers = they don’t want speed. They want safety.

why the pricing is weird

New pricing went live this week. Three subscription tiers. And a Founder plan.

The prices are €9, not €8.99. €71, not €69.

This is deliberate. I’ve been calling it “anti-marketing pricing.” Round numbers that don’t pretend to be cheaper than they are. No countdown timers, no “only 3 seats left” urgency, no annual-only tricks to inflate LTV metrics.

Every feature is available on every plan. There are no locked capabilities. If you’re on the smallest plan at €9/month, you get the same 172 tools as someone paying €309/year. The tiers differ by how many websites you manage. Nothing else.

I thought about this for a long time. There’s a concept from Adlerian psychology called Gemeinschaftsgefühl. It translates roughly to “community feeling through contribution.” The idea is that belonging comes from what you give, not what you consume.

That became the design principle for everything.

The Skills Marketplace - 26 AI workflows for audits, migrations, accessibility fixes, SEO optimization - is free for every user. Open-source on GitHub. Community-built. You use a skill, you improve it, you share your own. The value compounds because everyone adds to it.

The Founder plan isn’t a premium tier with exclusive features. It’s five seats worldwide, €5,001 each, with quarterly calls where those five people shape what gets built next. It’s not about access. It’s about influence and contribution.

I don’t know if this pricing philosophy will work at scale. Most SaaS advice says to gate features, create urgency, and optimize for annual prepayment. I’m doing none of that. But the 100 people who already paid seem to appreciate it. And I’d rather build something that 1,000 people genuinely value than something that 10,000 people tolerate because they’re locked in.

building alone, in public

People ask me how I build this alone. The honest answer: I don’t, really.

Claude Code writes the PHP and TypeScript. I make the architectural decisions, design the user experience, write the copy, talk to customers, and decide what to build next. The AI is my engineering team. I’m the product person, the designer, and the founder.

Understanding what people need, how they think about value, where the friction is. The AI handles the part I was never great at (writing thousands of lines of production code). I handle the part AI is still bad at (knowing what to build and why).

I share everything publicly. The telemetry is live on the homepage - real numbers, not cherry-picked metrics. The release notes explain not just what shipped but why and what was broken before. When users find bugs, I publish the bugs and the fixes together.

This transparency costs something. A competitor can read my entire playbook. A skeptic can see my rough edges. But it earns something too: the 100 people who paid did so with full information. They knew exactly what they were buying, including the parts that weren’t finished yet.

I think that’s worth more than any growth hack.

what’s next

A free version of the plugin for WordPress.org. A 12th page builder. A dashboard redesign that I’ve been working on this week (the current one looks like it was built at 2am, because it was) - oh, this was was done before finishing the article :).

And the Slack community just opened. Support each other. Share what you’re building. Give more than you take, so there’s always something to take.

Mihai
Brașov, Romania

4 April 2026

And yet.

Someone will connect the latest flagship Claude Code model on thinking-hard mode to their WordPress site through 103 MCP tools, type “make my homepage better”, and then blame the AI when the result is generic.

That’s not a tools problem. That’s a GiGo problem.

Garbage In, Garbage Out

GiGo was coined in 1957. It predates the internet, personal computers, and your page builder. And it’s more relevant now than ever, because the tools got so good that the bottleneck quietly shifted to the other side of the keyboard.

When the tool was a hammer, you didn’t blame it for a crooked nail. But when the tool talks back in perfect paragraphs and sounds more confident than your project manager, it’s easy to forget that it’s still waiting for you to aim.

What GiGo looks like in practice

Garbage in:

“make my services page look better”

The AI hears: change things. Which things? Better how? More modern? More minimal? More like a competitor you haven’t mentioned? It doesn’t know your brand, your audience, or what “better” means to you. So it guesses. And guesses are generic by definition.

Gold in:

“Rewrite the hero section on my services page. Keep the h1 but rewrite the subtitle to focus on client outcomes, not features. Same Divi section structure. Match the tone of the About page. Don’t touch anything below the fold.”

Same AI. Same tools. Same page. Wildly different output. The difference is the instruction, not the intelligence.

The three things you’re skipping

Context. The AI doesn’t know your business. It doesn’t know your services page gets 40% of its traffic from Google Ads and visitors bounce at the hero. If you don’t say it, it doesn’t exist.

Constraints. AI with no boundaries produces average work because average is the center of its training data. “Build me a landing page” is a prayer. “Single section, one headline, one paragraph, one CTA, black on white, under 50 words” is creative direction.

References. “Make it modern” means nothing. “Match the layout of stripe.com/payments with our color palette in a Bricks section” means everything. AI is great at pattern matching. Give it a pattern.

The 5-second test

Before you hit enter, ask yourself: could three different people read this prompt and imagine three completely different results?

If yes, it’s garbage. Not because it’s stupid. Because it’s ambiguous. And ambiguity is the raw material of mediocre output.

The format that works

What: specific action on specific element
Where: which page, which section, which builder
Why: the goal you’re solving for
How: tone, style reference, constraints
Don’t touch: what stays the same

Example:

Rewrite the pricing section on /services. Bricks section, three columns. Current copy lists features but sales calls show clients care about time saved. Rewrite each column to lead with the outcome. Keep layout, buttons, and pricing numbers. Leave the FAQ below it alone.

That prompt takes 30 seconds longer to write and saves you three rounds of “no, not like that.”

The oldest law in computing

WordPress is powerful. AI models are powerful. Respira connects them with 103 tools across 11 builders and a safety net that captures every edit. But none of that fixes “make it better.”

You’re the creative director. The AI is waiting for direction.

GiGo. 1957. Still undefeated.

respira.press — 103 tools. 11 builders. The safety net is there. The creative direction is yours.

There’s an old parable about two builders working on opposite sides of the same mountain. Neither can see the other. Both are digging toward the center. One morning, they break through and realize they’ve been building the same passage from different directions.

Today felt like that.

I.

WordPress powers roughly 42.5% of the web. For twenty years, most of those sites have been managed the same way: you open the dashboard, click through menus, edit fields, and press publish.

The tools changed. The interaction model didn’t.

Gutenberg replaced the classic editor. Page builders like Elementor and Divi added drag and drop. But the basic flow stayed the same: human opens interface, human makes changes, human saves.

Today, that started to change.

Two different teams shipped two different products that break the model in the same direction: you talk to your site, and it changes.

II.

The first launch came from Automattic.

WordPress.com flipped the switch on write-capable MCP tools for paid sites, which means AI agents like Claude, ChatGPT, and Cursor can now create and edit content through conversation. You can ask for a draft, a new page, taxonomy changes, comment management, or media metadata updates, and the agent handles the work after asking for approval.

There are nineteen new write tools in total. The system also reads the site’s design language, colors, fonts, spacing, patterns, so the result looks like it belongs there.

It is a clean implementation, and for WordPress.com users it meaningfully reduces the distance between intention and publishing.

III.

The second launch was mine.

I shipped Respira for WordPress 5.0 Haven on the same day.

I build Respira, so this is not a neutral review. But the contrast matters, because these two products solve different parts of the WordPress world.

WordPress.com starts from a controlled platform. Respira starts from the messier, more interesting side of WordPress: self-hosted sites, mixed hosting setups, custom themes, and page builders with wildly different internal formats.

The difference is easier to show than explain, so let me start with a story.

IV.

A few weeks ago, a user sent me a message after approving a page edit through Respira.

The page was in their header menu. When they approved the duplicate, the original page went private. The menu link broke. Visitors clicked the header and landed on a 404. That is the kind of bug that makes people uninstall software. Not because it is especially complex, but because it violates a promise. The workflow that is supposed to keep your site safe becomes the thing that breaks it.

I fixed the immediate issue. Merge mode now writes the duplicate content back into the original post, preserving its ID, URL, and every reference pointing to it.

But that fix exposed the bigger problem.

Using Respira myself, I noticed I had started skipping the duplicate workflow when I wanted speed. I would tell Claude to edit the live page directly, because it was faster and usually good enough.

And when I did that, there was no real way back.

WordPress revisions store the title, content, and excerpt. But builder data, the Elementor layout, the Divi modules, the Bricks elements that define how the page actually works, often lives outside what revisions capture.

So I built the undo button.

V.

Every WordPress edit done through Respira for WordPress now creates a full-fidelity snapshot automatically.

Not just the post content. The builder payload, metadata, custom fields, and the pieces WordPress revisions usually miss. The snapshot is compressed, hashed for fast comparison, and stored in a dedicated table.

There’s a new Changes page in the admin dashboard. Every post with Respira activity gets a timeline: pending duplicates at the top, full version history below. You can preview diffs between any two states and restore with one click. The restore itself creates a safety snapshot first, so even undoing an undo is possible.

Pinned versions survive all cleanup. Star a version to keep it forever. The state right before a redesign, the last version a client approved, whatever matters to you.

And every write operation through MCP or WebMCP now auto-snapshots before mutating. The AI can edit freely. The safety net catches everything.

That’s Respira 5.0 Haven. The name felt right. A haven is a safe place. That’s what the undo button provides.

VI.

So yes, these are two launches in the same category. Both let AI agents write to WordPress.

But they come from opposite constraints.

WordPress.com starts from the platform side. They control the hosting, the editor, the account system, and the theme layer. They can offer a toggle because they own the full stack. Their design-aware writing works cleanly because the design system is already theirs. Their write tools fit naturally because Gutenberg is the native editor.

Respira starts from the other side: self-hosted WordPress.

That means different hosts, different themes, different plugins, and eleven different builders, each with its own content format and internal logic. Some store layout as JSON. Some use shortcode trees. Some hide critical structure in meta fields. There is no single design system to read and no universal content format to trust.

Teaching an AI agent to work safely across that terrain has been my obsession for the last four months.

VII.

The difference becomes obvious the moment you try editing a builder site through the REST API.

With Gutenberg, you usually get structured blocks back. You can read them, modify them, and write them back in a fairly direct way.

With page builders, the page often looks editable until you realize the real layout data lives somewhere else.

Elementor may keep the real structure in post meta. Divi relies on shortcode hierarchies. Other builders have their own storage models and schemas. The page you see in the editor is not always the page the API gives you.

That is the problem Respira solves.

Not “write some text into WordPress.”
Write natively into the builder the site already depends on.

VIII.

I could keep describing the technical problem. Or I could show you what it looks like when it's solved.

After I finished the release, I wanted to test that claim properly.

So I sat down with Chrome 146+, the Claude browser extension, and a WordPress site running Divi 5. I gave Claude one prompt: create a stunning Divi5 landing page that shows what Respira can do, explain how it was built, and document the tech stack behind it.

One prompt. One conversation. No manual code. No dragging modules around in the visual builder. No copying layouts from somewhere else.

Claude read the site context through Respira’s MCP tools. It understood the Divi 5 format through Respira. It designed a multi-section page with a hero, capability sections, a tech stack explanation, a build timeline, micro interactions + animations, and calls to action. Then it wrote the page and published it live through the builder’s own structure.

The result is a native Divi 5 page, not pasted HTML pretending to be one.

The result is at mihai.love/respira.

The page documents exactly how it was made, including the prompt that created it. This is a native Divi 5 page. Not Gutenberg blocks dropped into a Divi site. Not HTML injected into the post body. Actual Divi 5 sections, rows, columns, and modules, placed through the builder's own content format. The kind of page that would take a designer a full day to build manually.

That is what builder-specific intelligence looks like in practice. The AI is not just filling a text field. It is speaking the builder’s language.

IX.

There’s a question underneath both of today’s launches that I think about a lot: what happens when the AI gets it wrong?

For Respira, I needed a different safety model.

When an AI agent edits a live Elementor or Divi landing page, “it starts as a draft” does not really apply. The thing being changed is often already live. And asking permission is only the first layer of safety. You also need to see what changed, compare it to what came before, and restore the full state in one click, including the builder data WordPress revisions do not preserve.

That is the gap Haven fills.

This is not a criticism of WordPress.com’s approach. It is a difference in terrain. Hosted Gutenberg sites and self-hosted builder-heavy sites need different kinds of safety. The safety infrastructure has to match the terrain.

X.

I did not plan to launch Haven on the same day as WordPress.com.

The work was already underway because of that broken-menu bug and the product question behind it: if Respira already captures full-fidelity snapshots, and WordPress already has native revisions, why can’t users actually see and use that history properly?

So I built the missing layer: merge mode that preserves identity, a Changes page that exposes the timeline, and automatic snapshots around every write action.

Then WordPress.com shipped their launch, and I pushed mine too.

I think the overlap says something real about where WordPress is headed. The infrastructure is converging. Core AI work is moving. MCP is no longer a side conversation. The question is no longer whether WordPress will be editable through agents. It already is.

The infrastructure is converging. WordPress 7.0 ships April 9 with a “Try AI” callout on the about page. The WordPress/ai repo on GitHub has commits from hours ago. The Abilities API is maturing in core. The MCP Adapter is being actively discussed as a standalone plugin or as part of the AI experiments plugin.

I commented on PR #152 this week with technical notes from running 100+ WordPress Abilities in production. I’ve been talking with other plugin developers about how to register abilities well. I’m watching the core-ai team build the foundation in real time, and I’m trying to make sure page builder sites can be part of it.

XI.

So where does this leave us?

If your site is on WordPress.com and you use Gutenberg, today is a good day. Toggle on the write tools and start talking to your site. The onboarding is smooth and the design awareness is a smart touch.

If your site is self-hosted and built with Elementor, Divi, Bricks, or the rest of the builder ecosystem, this is also a very good moment. Respira 5.0 Haven gives you 103 tools, builder-aware editing, and a rollback model designed for live site work. Every change is visible. Every restore is reversible.

If you’re a developer or agency managing multiple sites across both worlds, you probably need both. WordPress.com MCP for your hosted clients. Respira for your self-hosted clients. The tools don’t conflict because they serve different sides of the ecosystem.

And if you were still wondering whether AI agents editing WordPress is real or just another hype cycle, today answered that.

Two teams shipped from opposite sides of the ecosystem on the same day.

The tunnel is almost through.

The detailed side-by-side comparison with scenario breakdowns: respira.press/blog/respira-vs-wordpress-com-mcp

The full 5.0 Haven release story: respira.press/releases/5.0.0

WordPress.com’s announcement: wordpress.com/blog/2026/03/20/ai-agent-manage-content

I’m Mihai. I build Respira from Brașov, Romania. Solo founder, father of two, and still very interested in making WordPress less painful to change.

If you are working in the WordPress AI space, say hi in #core-ai on WordPress Slack.

i got my first refund request three months into running respira for wordpress.

€199. order #xyz. a customer named M.P. who was “genuinely excited on day one” but ran into walls i didn’t know existed.

he asked for his money back under my 30-day guarantee. i gave it to him immediately—no questions, no negotiation, no “let me help you debug this” dance.

but then i did something that changed the trajectory of the product.

i read his email again.

the email that became a roadmap

here’s what M.P. told me (lightly edited):

“Claude token usage is significantly higher than when working locally, which blows through my budget much faster than expected.”

“The approval interface is hard to navigate: Respira creates multiple copies of pages, and I was unable to figure out how to ensure the correct page gets updated.”

“Multi-site management is too complex: configuring the claude.json file and the switch site feature don’t work reliably for me.”

three problems. specific. actionable. brutally honest.

and every single one was correct.

the part where i could’ve gotten defensive

there’s a moment when you read feedback like this where your brain offers you a way out:

“well, most users figure it out”
“maybe he didn’t read the docs”
“power users don’t mind a little complexity”

i’ve built software for 24 years. i know this voice. it’s the voice that protects your ego at the expense of your product.

M.P. didn’t owe me debugging time. he didn’t owe me patience. he paid €199 for a tool that would make his work faster, and it was making his work slower.

the product wasn’t good enough. full stop.

instead of excuses

i took his three pain points and turned them into three features.

problem 1: token usage burning through budgets

respira was sending verbose json payloads back and forth with claude. complete. thorough. and expensive.

i rebuilt the mcp response system to be compact by default. discovery + patch flows instead of full payload extraction.

result: 60-70% token reduction on typical wordpress editing workflows.

M.P. was right. it was too expensive.

problem 2: approval interface creating duplicate chaos

every edit created a new duplicate. five duplicates for one page. which one has the latest changes? which one should i approve?

i added working copy consolidation. the system now reuses the latest open working copy instead of creating new duplicates. older versions get archived to history.

result: one clear “approve this” button. no more guessing.

M.P. was right. it was confusing.

problem 3: multi-site setup requiring json surgery

manual json editing. unclear which site was active. switch failures.

i built a dashboard config generator that exports installer commands and ai setup prompts. zero manual json editing. one-time install tokens. client-specific configs.

result: copy command, run in terminal, done.

M.P. was right. it was too complex.

the dedication

i shipped all three fixes as respira 4.2.0 in 9 hours after reading the refund request.

i dedicated the release to M.P., the customer who gave me the feedback i needed to hear.

at the bottom of the release page, there’s a dedication:

“This release is dedicated to M.P., who gave us the specific feedback we needed to make Respira better for everyone. Your three pain points became our three biggest improvements. Thank you for being honest, for asking for your money back, and for saying you’d give us another shot. This one’s for you.”

he said in his email: “I fully intend to come back and try it again in a few months.”

this release is specifically designed to make that return successful.

what refunds actually mean

i’m a solo founder. respira is nights and weekends.

that €199 refund was real money. it hurt.

but here’s what else was real:

260 WordPress sites using the product. 271,236 lines of code shipped through ai assistants. 3,022 pages edited, 284 posts edited. 4,238 ai agents connected across Claude Code, Cursor, and Codex.

one refund doesn't mean the product is broken. it means one person found the exact edges where it breaks.

and if you’re building something real, those edges are gold.

the alan watts angle

there’s an alan watts quote i keep coming back to:

M.P.’s refund request was change. unexpected. uncomfortable. the first one always is.

i could’ve resisted it. gotten defensive. written it off as an edge case.

instead i plunged into it. moved with it. joined the dance.

and the product got better.

building in public actually means listening

“building in public” has become startup performance art. post your revenue. share your struggles. cultivate vulnerability as a brand strategy.

but real building in public means this:

when someone tells you your product isn’t good enough, you believe them.

you don’t spin it. you don’t rationalize it. you don’t wait for three more customers to say the same thing.

you fix it.

M.P. gave me three specific, actionable problems. i shipped three specific, actionable fixes.

that’s the dance.

what’s next

if you’re running WordPress sites and hitting token budget limits, approval confusion, or multi-site setup friction—respira 4.2.0 fixes all three.

if you’re building a product and you get a refund request with specific feedback—read it twice. then ship the fixes.

and if you’re M.P. reading this: thank you. seriously. come back when you’re ready. this one’s for you.

release notes: https://www.respira.press/releases/4.2.0
github: https://github.com/webmyc/claude-skills-wordpress

building respira for wordpress from brașov, romania.
nights and weekends.
simple systems that breathe.

p.s. - if you’re a solo founder who’s gotten that first refund request and felt the gut punch, reply to this email. i want to hear your story.

Mihai here from Brașov. Father of two, building Respira between school runs and bedtime.

It’s been three months since I started building this thing. Twenty-three of you bought launch licenses (18 Starter, 5 Agency). 176 WordPress sites are now using Respira. 949 pages edited. 31,797 lines of code written by AI through Respira for WordPress.

That’s surreal to me. Thank you 🙏

I wanted to share what we shipped this month and some unexpected things happening around Respira for WordPress.

What We Built This Month

➜ Comprehensive About page with real use cases

Not marketing fluff. Six actual scenarios based on who you are and what you need:

• WordPress User → Build without code fear

• AI Curious → Guided AI, safest place to start

• Agency → Scale multi-site operations

• Vibe Coder → Build at speed of thought with MCP orchestration

• Developer → AI co-pilot for complex stacks

• Designer → Figma to WordPress, direct

Each page shows exactly how Respira fits your workflow. Check it out at respira.press/about

➜ Divi 5 support + migration co-pilot

Divi 5 launched. It’s a complete rewrite from modules to blocks.

Respira now supports the new block system and gives you a migration co-pilot. It complements the official Divi migration tool but adds safety: test on duplicates first, approve what works, keep what doesn’t.

Don’t auto-convert everything and hope. Test. Review. Approve.

Full Divi 5 and Divi 4 support details: respira.press/divi

➜ WebMCP support for Chrome 146+ (this is big)

88 AI tools now available directly in Chrome beta. Brand new browser MCP technology.

The beauty: you don’t need to install the WordPress WebMCP Abilities plugin that isn’t even released yet.

Just enable Experimental WebMCP in chrome://flags and you get all 88 tools (browser + desktop) working with Claude, Cursor, Codex, and any MCP-compatible AI.

This is the future. AI assistants talking directly to WordPress through the browser.

Setup guide: respira.press/docs/browser-ai

➜ ADA/WCAG compliance scanner (experimental)

Stay away from accessibility fines.

Right now it’s experimental. Chrome extension coming soon. The exciting part: it gives you fixing prompts specific to your page builder.

Not generic “fix this” but “here’s the Elementor widget update to make this compliant.”

Learn more: respira.press/addons/accessibility-scanner

➜ Community launched - choose your channel

GitHub Community or Discord. Your choice.

GitHub for bugs, features, documentation - anything that should be searchable in 6 months.

Discord for real-time help, quick questions, community vibes.

Philosophy woven through both: give more than you receive. Socrates’ triple filter (is it true? is it kind? is it useful?).

Excited to see what you build and how you use Respira.

➜ WooCommerce Add-On

Product descriptions, SEO optimization, bulk updates across your store.

Works with WooCommerce product pages just like regular WordPress pages. Duplicate-first, review, approve.

Details: respira.press/addons/woocommerce

➜ Multiple bug fix patches shipped

Thanks to everyone who reported bugs! We shipped fixes for:

• Elementor (all checks passed)

• Bricks (all checks passed)

• Oxygen (all checks passed)

• Beaver Builder (all checks passed)

• Visual Composer (all checks passed)

Your bug reports make Respira for WordPress better for everyone. Keep them coming.

What’s Happening

Some interesting conversations are starting.

A few agencies reached out asking about integrating Respira into their workflows. One major page builder wants to explore collaboration (more on that when there’s something concrete).

Why this matters to you: if these conversations turn into partnerships, it means better builder support, more features, faster development.

But right now? Still just me. 176 sites. 949 pages edited. 31,797 lines of code written through Respira. Still building between school runs.

Nothing changes about my commitment to you.

Launch Licenses Running Out

63 Starter seats left (€19/year, locks in forever)
23 Agency seats left (€199/year, locks in forever)

After that, prices go to €19/month and €199/month.

Licenses are stackable. If you’re getting value and want to grab more sites at launch pricing, now’s the time.

Once they’re gone, pricing changes.

See current pricing: respira.press/pricing

Thank You

Building something people actually use is different from building something alone and hoping.

Every time someone emails saying Respira saved them hours on a client project, or helped them try AI for the first time without breaking their site, or made bulk operations actually manageable - that keeps me going more than any revenue number.

So thank you for using this thing. For reporting bugs. For suggesting features. For showing up in the community.

You’re helping me figure out what Respira becomes.

Keep building. Don’t break things. Use duplicates.

— Mihai
Brașov, Romania
word@respira.press

P.S.

New to Respira for WordPress? Start here: Getting Started Guide - or just feed it to your AI, it will need what it has to do and will ask you what it needs :)

Quick Links

About & Use Cases

• What is Respira for WordPress?

• WordPress User

• AI Curious

• Agency

• Vibe Coder

• Developer

• Designer

Features & Add-ons

• Divi 5 Support

• Divi Migration Copilot

• WooCommerce Add-on

• ADA/WCAG Scanner

Get Started

• Documentation

• Browser AI Setup (WebMCP)

• MCP Server Setup

• Pricing

Community

• GitHub Community

• Discord

• Blog

983 pages edited. 28,045 lines of code written. 14 early adopters trusting me with their WordPress sites.

Three weeks ago, I launched Respira with a simple promise: let AI edit your WordPress sites without the fear of breaking things. The duplicate-before-edit workflow. Safety first. Always.

Today I’m sharing what we’ve built together based on your feedback, your edge cases, your “hey this broke” messages, and your “could it also do this?” questions.

What’s New

Breakdance Support (Builder #11)

Requested by three separate people in the first week. Breakdance is now fully supported with complete builder intelligence.

All 11 major page builders covered: Divi, Elementor, Gutenberg, Bricks, Oxygen, WPBakery, Beaver Builder, Breakdance, Visual Composer, Brizy, Thrive Architect.

The pattern is clear from usage data:

• Gutenberg: 44% of sites

• Elementor: 20%

• Divi: 8%

• Bricks: 4%

• Everyone else: scattered

But every builder matters when it’s your builder.

WooCommerce Integration (New Add-on)

Running a WooCommerce store? You can now manage products, orders, and inventory through AI coding assistants.

€7/month add-on. Same duplicate-before-edit safety. 7-day free trial.

If you’re running a WooCommerce store, you’re making sales - it’s only natural that a small portion of those returns helps us cover the cost of building and supporting the tools that manage your products and orders.

Create products. Update prices in bulk. Process orders. Track inventory. Generate sales reports. All through natural language with Claude Code, Cursor, or Codex.

The safety workflow extends to e-commerce:

• Products duplicated before editing

• Variations preserved exactly

• Limited order modifications (no financial accidents)

• Read-only for payment gateways

• 7-day grace period if subscription expires

WordPress Abilities API

Respira is now registered as an official WordPress Ability. Discoverable through the MCP Adapter. Part of the WordPress AI ecosystem.

This matters because it means other AI tools can find and use Respira automatically. No manual configuration. Just works.

Based on Your Feedback

The improvements that came directly from early adopters:

Better error messages - [redacted] hit an edge case with nested Divi modules. Error message was cryptic. Now it tells you exactly what’s wrong and how to fix it.

Faster page detection - [redacted]’s site has 200+ pages. Initial scan was slow. Now it’s cached and instant.

Multi-site handling - [redacted] manages 8 client sites. Switching between them was clunky. Now it’s one command.

Variation preservation - [redacted] duplicated a variable product and variations didn’t copy. Fixed. Now all variation data (prices, stock, images, attributes) copies perfectly.

Low-stock alerts - [redacted] requested this for WooCommerce. Before bulk stock updates, you now get warned if products will drop below threshold.

These weren’t on my roadmap. They came from you using this in production and telling me what broke or what was missing.

New logo for Respira for WordPress

Validation From Unexpected Places

A Reddit thread about AI agents and WordPress safety mentioned Respira as “the smart safety net that sandboxes ai edits on elementor/divi/gutenberg before they nuke your live pages.”

That caught the attention of danieliser, an WordPress Core Contributor, who’s building similar safety tooling for WordPress. His response:

“Two things that really landed:

1. ‘Duplicate-before-edit workflow’ — stealing this immediately. I’ve used that pattern in other agentic tools but somehow didn’t wire it into this one. Obvious in hindsight.

2. ‘Sandboxing is the product’ — perfect framing. In just a few days I went from fully trusting the AI to building structured, testable tooling the agent operates through instead.”

He’s building with WebMCP (browser-based, admin-side editing). We’re building with remote MCP (cloud-based, duplicate-first). Different trust models, same core insight: psychological safety matters as much as technical safety.

The fact that someone at WordPress, validated the approach and immediately adopted the pattern? That’s the kind of feedback that tells you you’re solving a real problem correctly.

The Documentation We Built

Three comprehensive guides released this week:

1. Safety Philosophy Documentation

Why duplicate-before-edit beats staging sites, git rollback, and admin-side editing. Comparison tables. Technical details. Real examples.

Includes the quote from danieliser (Anthropic engineer) who said: “Duplicate-before-edit workflow — stealing this immediately. Sandboxing is the product — perfect framing.”

2. WooCommerce Add-on Complete Guide

Everything about managing e-commerce with AI. Product management, order processing, inventory control, reports. What’s safe, what’s limited, what’s read-only. Example workflows that actually work.

3. Implementation Prompts for Developers

If you’re building similar tools or want to understand how this works under the hood: complete technical specifications for the WooCommerce integration, safety architecture, and multi-builder support.

Technical Support is Included

Every license includes technical support. This was always true but not emphasized enough.

• Starter (€19/year): Email support at word@respira.press

• Agency (€199/year): Priority email support

• WooCommerce add-on (€7/month): Support included

You email me directly. I respond, typically within 24 hours. No ticket systems. No support bots. Just: you have a problem, I help you solve it.

This isn’t a feature. It’s how I’m learning what needs fixing.

By The Numbers

Real stats from WordPress sites using Respira:

983 pages edited through AI assistants 17 posts created or updated 28,045 lines of code written by AI (page builder JSON, shortcodes, HTML)

Builder distribution:

• Gutenberg: 95 sites (44%)

• Elementor: 43 sites (20%)

• Not detected: 40 sites (18%)

• Divi: 18 sites (8%)

• Bricks: 8 sites (4%)

• Everyone else: scattered small numbers

Launch offer progress:

• 14 licenses sold (12 Starter, 2 Agency)

• 86 lifetime-price seats remaining

• Early adopters lock in €19/year forever (vs €19/month after launch)

Personal Thanks

To the first 14 who trusted me with their WordPress sites:

Brad, Wayne, Domenico, geoff, Eric, Keith, Harald, Fabio, Lucas, Martijn, Shon, Stephen, Scott - and M (whoever you are with just the initial).

You’re not just customers. You’re co-builders. Every bug report, edge case, feature request, and “this is confusing” message makes Respira better for everyone who comes after.

Your feedback shaped:

• Which builders to prioritize (Breakdance came from you)

• How error messages should read (clear, not cryptic)

• What safety features matter most (variation preservation, low-stock alerts)

• Where documentation was missing (hence the three new guides)

You’re getting 92% off because you’re helping me figure this out. That’s the deal. And it’s working.

What’s Next

Lite Version on WordPress.org - Free version is ready, just needs submission to the WordPress directory. Gutenberg support only, 30 edits per month, perfect for trying AI editing risk-free before upgrading to the full version with all 11 builders.

Theme Builder Support - Headers, footers, archive templates. Most requested feature for Divi and Elementor users.

Visual Diff Tool - See changes visually, not just code. Side-by-side comparison of duplicates vs originals.

Pattern Recognition - AI learns your common layouts and replicates them more accurately.

More WooCommerce Features - Subscription support, booking support, bundle support (if you use these extensions, let me know).

If you’re thinking about it: the free trial exists specifically so you can test on real sites before deciding. Use it.

The Philosophy

I’m building Respira solo. 44 years old. Father of two. Based in Brașov, Romania. 24 years building on WordPress.

The approach is simple: ship fast, learn from real use, improve based on actual feedback, stay transparent about what works and what doesn’t.

“Sandboxing isn’t overhead, it’s the product.” That quote from the Anthropic engineer captured it perfectly. The duplicate-before-edit workflow isn’t a feature - it’s the entire point. It’s what makes you trust AI with your production sites.

Everything else (the builder intelligence, the 50+ MCP tools, the WooCommerce integration, the WordPress Abilities API) exists to make that safe workflow actually useful.

Try It

7-day free trial. No credit card required. Technical support included.

Launch pricing: €19/year for 1 site. €199/year for 20 sites. Lock in these rates forever.

86 lifetime-price seats left. After that, same features become monthly pricing.

Start free trial →

If you’re already using Respira: thank you. Tell me what’s breaking, what’s confusing, what’s missing. I’m listening.

—mihai

p.s. If you’re one of the 14 early adopters and I got your name wrong in the thanks section, email me. I pulled these from the customer list and some just show initials.

i created a new section on my Substack for Respira for WordPress updates.

this will be product development stories, technical insights, early adopter feedback, and building-in-public progress on making AI safely edit WordPress sites.

you’re automatically subscribed because you’re on my main list.

if you’re interested in following this journey, no action needed.

if you’d rather not get Respira for WordPress updates:

1. go to https://respira.love/account

2. uncheck “respira.press”

3. you’ll keep getting everything else i write

no hurt feelings either way. this section will be technical and product-focused. not for everyone.

Not a plugin update or a theme release. Something more fundamental. WordPress is becoming AI-native —> and the pieces are falling into place faster than most people realize.

If you’re a developer managing WordPress sites, or a site owner wondering what all the MCP talk means, here’s what’s actually happening and what you can do with it today.

Disclaimer: Parts of this article have been written with the help of Claude Opus 4.6 and based on my work and codebase of Respira for Wordpress, a plugin and MCP that teach Cursor (or any AI text-to-code tool) how to speak the language of Divi, Elementor and other 8 most popular WordPress page builders to safely edit your live site through prompting.

The news, in order

February 4, 2026 — The WordPress Developer Blog published “From Abilities to AI Agents,” introducing the official MCP Adapter. This bridges WordPress’s new Abilities API (shipped in WordPress 6.9) to the Model Context Protocol, the open standard Anthropic created for connecting AI systems to external tools. Any WordPress plugin can now register abilities that AI assistants discover and execute automatically.

February 5, 2026 — WordPress.com launched its Claude Connector, covered by TechCrunch. You can now connect Claude directly to your WordPress.com site through the Connectors directory. Ask about your traffic, query your comments, check plugin status — all through conversation. Read-only access for now, with write capabilities planned.

February 8, 2026 — WordPress 7.0 Beta 1 was confirmed for February 19, with the final release targeted for April 9 at WordCamp Asia. This is the big one. WordPress 7.0 brings real-time collaboration (Google Docs-style), the Abilities API moving deeper into core, MCP Adapter support, and a WP AI Client that gives WordPress a provider-agnostic way to call AI services natively.

Also happening — WooCommerce published MCP integration documentation, exposing store operations (orders, products, customers) as MCP tools through the Abilities system. The WordPress AI Team meets bi-weekly on Slack (#core-ai), actively coordinating the merge of AI building blocks into core ahead of the beta.

This is not incremental. This is WordPress building a standardized AI interface into its foundation.

What each piece actually does

Let me break this down practically, because the terminology gets tangled fast.

The Abilities API is the foundation layer. It lets WordPress core, plugins, and themes register what they can do in a machine-readable format. Think of it as WordPress creating a menu of capabilities that any system — human or AI — can browse and invoke. Introduced in WordPress 6.9, it’s becoming central to how WordPress interacts with the outside world.

The MCP Adapter sits on top of Abilities. It translates those registered capabilities into the Model Context Protocol format, so AI tools like Claude Desktop, Cursor, Claude Code, and VS Code can discover and use them. If your plugin registers an ability, the MCP Adapter makes it available to AI assistants without extra integration work.

The WordPress.com Claude Connector is the consumer-facing implementation. WordPress.com users connect Claude to their sites through a simple OAuth flow. Currently supports querying site data — analytics, content, comments, settings. It’s the “Claude, tell me about my site” experience. Write access is coming.

Third-party MCP servers — several exist on npm and GitHub (InstaWP, Meow Apps AI Engine, and others). They connect AI assistants to the WordPress REST API for managing posts, pages, plugins, media. Standard CRUD operations. Some are quite mature.

Together, this creates a real ecosystem. Not a single tool — a layered infrastructure that developers and AI tools can build on.

The gap that’s still open

Here’s where it gets interesting — and where I need to be honest about my own work, because I built something specifically for this.

All of the solutions above work through the WordPress REST API. The REST API understands WordPress core data structures. Gutenberg blocks, posts, pages, taxonomies, settings — it handles all of that well.

But roughly 40% of WordPress sites don’t use Gutenberg as their primary editor. They use page builders. Divi, Elementor, WPBakery, Bricks, Oxygen, Beaver Builder, and others.

These builders store content in proprietary formats. Divi uses shortcodes with a specific module structure. Elementor stores everything as JSON blobs. Bricks has its own element format. When you ask the REST API to read a Divi page, you get raw shortcode soup. When you try to write to it, you’re likely to break the layout entirely.

This means that right now, if you’re a developer using Cursor or Claude Code and your client’s site runs Divi or Elementor, the official MCP tools can’t help you edit individual page builder modules. They can manage posts and settings, but they can’t safely change a specific button, update a hero section, or modify a pricing table at the component level.

That’s the problem I’ve been working on.

What I built for page builders

Respira for WordPress is a plugin paired with an MCP server — @respira/wordpress-mcp-server on npm — that adds two layers the current ecosystem doesn’t have:

Page builder intelligence. Respira teaches AI how each builder structures its content. Complete module-level awareness for Divi (200+ modules), Elementor (every widget and control), Gutenberg, WPBakery, Oxygen, Bricks, Beaver Builder, Brizy, Visual Composer, and Thrive Architect. When you tell Cursor to “make the hero heading larger,” Respira knows whether that’s a Divi text module, an Elementor heading widget, or a Bricks element — and generates the correct syntax for whichever builder the page uses.

Duplicate-before-edit safety. Every edit happens on a copy. AI never touches your live page directly. You review the changes, approve or reject. If you reject, nothing happened. Your original page is exactly as it was.

The MCP server connects to Cursor, Claude Code, Windsurf, or anything that supports MCP:

bash

npx @respira/wordpress-mcp-server --setup

Beyond editing, the same toolset includes SEO analysis, Core Web Vitals checks, and AEO (Agentic Engine Optimization) — tools that help your site surface properly in AI-powered search engines like ChatGPT, Perplexity, and Claude.

How it fits with the official ecosystem

This is important to say clearly: Respira isn’t competing with the official WordPress AI infrastructure. It’s complementary.

The Abilities API and MCP Adapter are the right foundation. They’re being built thoughtfully, with proper permission models and extensibility. I’m working on registering Respira’s page builder tools as WordPress Abilities so they’re discoverable through the official MCP Adapter too. One plugin, visible through both paths.

The Claude Connector gives WordPress.com users a clean entry point to AI-assisted site management. When it gains write access, the page builder understanding layer becomes even more relevant — you’ll need something that knows how to write Divi syntax correctly, not just pass through generic content.

The landscape is forming. The official pieces handle Gutenberg and core WordPress beautifully. Respira handles page builders. Different tools for different architectures, same ecosystem.

What this means for WordPress developers right now

If you haven’t started experimenting with MCP and WordPress, now is genuinely the time. Here’s what you can do today:

For Gutenberg sites — Set up the WordPress MCP Adapter on a local or staging site. Register some abilities. Connect Cursor or Claude Desktop. The WordPress Developer Blog tutorial from February 4 walks through every step.

For WordPress.com sites — Enable the Claude Connector in your account settings. Start querying your site data conversationally. It’s read-only for now, but it’s a preview of where everything is heading.

For page builder sites — Install Respira on a test site, connect @respira/wordpress-mcp-server to your AI assistant, and try editing a Divi or Elementor page through natural language. Free 7-day trial, no credit card required.

For everyone — Watch the WordPress 7.0 beta on February 19. The convergence of real-time collaboration, native AI infrastructure, and MCP support makes this the most significant WordPress release in years.

WordPress has always been the most adaptable CMS. Now it’s becoming the most AI-accessible one too. The foundation is here. The pieces are connecting. The only question is what gets built on top of it.

Mihai Dragomirescu builds digital infrastructure for creators and small businesses at Respira. Follow the build-in-public journey at respira.love.

Respira

1.24MB ∙ PDF file

Download

Download

Or just enjoy the story

There’s this moment that kept happening.

A client would call. Someone who’d spent fifteen years developing their practice, their approach, their language. They’d finally gotten their old WordPress website to a place that felt right.

Then they’d want to change something small. A button. Some text. Maybe update their bio across three pages. Or just create a brand new landing page for a retreat.

And they’d have three options:

Ask their tech person (me, or someone else)

Try to do it themselves in Divi or Elementor and... maybe break something

Just not do it

Most of them chose option three.

Not because they couldn’t find help. Because the friction was too high. Because by the time they’d explained what they wanted and someone had time to do it, the moment had passed.

Their websites became frozen. Not broken - frozen. Stuck at “good enough” because change felt hard.

And on my side? i wanted to help faster. To take “can you change this button” and turn it into “done” in five minutes instead of finding time, making the edit, testing it, and following up. The work itself was simple. The process around it wasn’t.

These are people whose work is about evolution. About becoming. Their online presence should be able to keep up.

Then I started vibe coding.

That’s what they call it when you use AI assistants like Cursor or Claude Code. You describe what you want in plain English. The AI writes the code. You’re not really a developer anymore - you’re a translator between intention and execution.

It changed how i work. Completely.

I could build things i couldn’t have built before. Faster. With more room to experiment. The AI handled the syntax, the structure, the technical details. i handled the vision.

But there was a gap.

The AI couldn’t talk to WordPress. Not in a way that understood page builders. Not in a way that was safe.

I could tell it “make all the Contact Us buttons green” but it didn’t know how to find those buttons in Divi. Or Elementor. Or any of the ten different ways WordPress stores content depending on what builder you’re using.

And even if it could find them, any change went straight to the live site. No undo. No review. One wrong instruction and you’re looking at a broken homepage.

This wasn’t a tool i could hand to my clients. It was a tool i couldn’t even fully trust myself.

What was actually missing wasn’t the connection between AI and WordPress. The WordPress REST API exists. The technical bridge is there.

What was missing was the safety layer.

The understanding layer.

The thing that says: “i know you want to change this, let me duplicate the page first, make the change on the copy, show you the result, and only publish it if you approve.”

The thing that speaks Divi when you’re using Divi. Speaks Elementor when you’re using Elementor. Understands that these builders store content in completely different ways and that AI needs different instructions for each one.

That’s what i built.

Respira for WordPress is the bridge I needed.

You tell your AI assistant what you want. Respira translates it into the language of your page builder. The edit happens on a duplicate. You review. You approve. Then and only then does it go live.

If you don’t like it, nothing happened. Your original page is exactly as it was.

This sounds obvious. It wasn’t obvious to build.

Page builders are a mess. Divi stores content as shortcodes in the database. Elementor uses JSON. Gutenberg is blocks. Getting AI to understand all of them meant building separate intelligence for each one.

That part took the longest. That’s also the part that makes this actually work.

There’s an official WordPress MCP now. WordPress announced it a few months ago - a standardized way for AI to talk to WordPress through the REST API.

It’s powerful. It’s built for developers who know WordPress internals. It’s the raw connection.

Respira is something else. It’s the translator and the safety net.

Different tools for different people.

Some things I’m still figuring out:

How to explain this to people who don’t know what MCP means (which is most people - and honestly, they don’t need to know)

Pricing that makes sense for a solo practitioner with one site and an agency with fifty

And what’s next:

SEO intelligence - letting AI rewrite your titles, meta descriptions, and tags based on what actually ranks

AEO (AI Engine Optimization) - optimizing for the new wave of AI search engines, not just Google. Structured data, clarity scoring, and the things that help LLMs understand and cite your content.

Internal linking - AI that reads your whole site and suggests connections you missed

Content rewrites - taking an existing article and restructuring it for readability, both human and machine

The editing layer was step one. Making your site findable is step two.

I built this because the gap between “i want to change something” and “it’s changed” was too wide for everyone involved.

For practitioners who want more autonomy over small changes.

For developers and freelancers who want to move faster on client work without the risk of breaking things mid-edit.

For agencies managing multiple sites who need efficiency without sacrificing quality control.

The work doesn’t disappear - it gets faster and safer. You can experiment, iterate, test different approaches. The AI handles the technical translation. You handle the judgment call about whether the result is right.

You can see it at respira.press. There’s a 7-day free trial. No credit card required.

If you have questions, reply to this. i read everything.

This is what build-in-public looks like. Not just the launches - the thinking behind them.

If you found this useful, share it with someone who manages WordPress sites and wishes it were easier.

Thanks,
Mihai