Why I'm Moving All My Clients Off Elementor  🔗 **Source:** [Why I'm Moving All My Clients Off Elementor](https://www.youtube.com/watch?v=3Om0WX4167I) > [!note]+ Document Notes > tags: [wordpress, elementor, claude-code, agency-workflow, vibe-coding, custom-development, web-design, ai-tooling] > author: Emanuel (I Create Your Site) — on Tyler Moore's channel > source: YouTube > reference: https://www.youtube.com/watch?v=3Om0WX4167I > date created: 2026-08-29 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Why I'm Moving All My Clients Off Elementor > > **Attribution — important correction to the surface metadata.** The video is published on **Tyler Moore's** channel, but the speaker is **Emanuel**, who introduces himself: "my name is Emanuel. I run a website design company called I Create Your Site where we've created over a thousand websites." Tyler appears *in the story* as the person who demoed Claude Code to him. Do not attribute these claims to Tyler Moore. > > **Standing.** Emanuel states he **used to work at Elementor** ("that's a story for a different video") and has built 1,000+ sites. That makes this an insider's defection rather than an outsider's critique, which raises its evidential weight and is worth stating. > > **Register.** **Practitioner testimony over a six-month period**, not a demo or a benchmark. Published 2026-08-28, 18:19. > > **Transcript provenance.** YouTube auto-captions via yt-dlp, reflowed into timestamped paragraphs. Recognition artifacts left intact inside quotes — "Clawude"/"cloud code" for Claude Code, "Chad GPT", "croco blocks" for Crocoblocks, "resend" for Resend, "Higsfield" for Higgsfield. > <!-- deep-read:sections start --> ## 🧭 Table of Contents 1. Summary 2. Main Content 3. References 4. Paraphrase 5. Newsletter 6. Action Items 7. Hypotheses 8. Methodology 9. Questions 10. Future Research 11. Implications 12. Learning Styles Assessment 13. Accessibility Assessment 14. DEIB Assessment 15. Logical Validity 16. DARVO Analysis 17. Conclusion 18. Refactor Appendix 19. Template Library ## 🔗 References (in-page) Named without links throughout: **Claude Code**, ChatGPT, Gemini, **Elementor**, WordPress, **JetEngine / JetSearch / Crocoblocks**, WooCommerce, Yoast, **Resend** (transactional email), **Higgsfield** (video generation), **Google AI Studio** (image generation), Stripe. No citations, no data, no external sources. This is unsourced first-person testimony by design. ## 📝 Summary **What happened.** Emanuel describes stopping WordPress and Elementor work in **February 2026** after Tyler demoed Claude Code building, in roughly 20 minutes, a real-estate site he had scoped as a multi-month build requiring a template, custom loops, a custom post type plugin, a map plugin, and JetEngine-class search tooling. Six months on, he builds custom sites, writes his own plugins instead of buying them, and has built a plugin that exposes a WordPress site to a Claude session for administration. **Why it matters.** This is the **operating-model evidence** that a demo alone cannot provide — six months of production work at an agency with a thousand sites behind it, from someone who worked at Elementor. His claim is stronger and more specific than the usual AI-replaces-tools argument: not that WordPress is bad, but that **most of his small-business clients never used the CMS they were given**. **Stakeholders.** Agencies whose economics rest on page-builder proficiency; Elementor and the JetEngine/Crocoblocks add-on economy; small-business clients; plugin vendors, whose product he now regenerates on demand. **Risks.** The security argument compares his best case to WordPress's worst case and does not survive that framing. More seriously, he reports deploying a plugin that grants an AI session administrative access across his client sites, in the same video where he argues custom sites are more secure — and never examines that surface at all. **Bottom line.** The durable finding is about **who the CMS was actually for**: he argues it was for the builder, not the client, and that once building is cheap the client-facing justification thins. That is a sharper claim than "AI replaces Elementor," and it is testable. ## 📖 Main Content ### 🗒️ Notes **The turning point, and its shape.** A February 2026 real-estate client with 90 rental units. His WordPress scoping: a real-estate template, custom loops, a custom post type plugin, probably a paid map plugin, and JetEngine or Crocoblocks for searching the custom post type. "It was going to be a complicated website to build." Then Tyler demoed Claude Code with a prompt describing those features: > [!quote] > and it ran and then 20 minutes later there was a full website with a map with the custom features with working search. Um it looked almost kind of like like Zillow, right? His reaction is careful: "it wasn't perfect, but I could see the writing on the wall." He does not claim the demo produced a finished product. **The misconception he names.** He had assumed Claude Code "was like an engineering tool and you had to be like a software developer," and that other models were "essentially chat GBT rappers" — the same prompt-in-text-out shape. That assumption is what had kept him away, and correcting it is what changed his practice. **The first move was hybrid, not replacement.** He used Claude Code to generate **JSON templates for Elementor** and to build custom plugins, while still shipping on WordPress. The full migration came later. **Why custom plugins beat purchased ones, in his account.** Not cost — fit: > [!quote] > if you purchase uh like a real estate um post type plugin, it's going to come with a million settings, default functions. Um you have to spend so much energy learning how to set up and and use the plugin before doing anything. The illustrative moment is small and telling: needing a placeholder image for listings without photos, he asked Claude to "add a setting to my plugin where I can assign one image to be the default image for all properties. It did that in two seconds." **Scope discipline, stated unprompted.** He addresses the vibe-coding safety objection directly and bounds it himself: "we're not vibe coding like payment processors." For a small business the needs are "like a calculator or maybe like a map feature um or like a widget" or a booking flow — "these are all things that you know are low stakes" and long-solved. Payments go through Stripe or an equivalent API. He also concedes the enterprise case outright: "If you're building that, you need an actual engineer to review the code before it gets published." **The WordPress-administration plugin.** This is the most consequential technical detail in the video and receives the least scrutiny: > [!quote] > I created a plugin that uh talks it ba the plug-in basically generates an API for your WordPress website and you put that API into your cloud session and uh it can just claude can log into your WordPress website. It can make changes to the pages to the element pages to the shop to the settings other plugins Yoast whatever the case may be. He says he "added it to all the customers that I had that had WordPress." The demonstrated payoff is real: a 2,000-product WooCommerce store, find everything with no sales in two years, review the list with the client, one click to draft — "That would have been hours and hours and hours." **On design and AI slop.** He is explicit that the design does not come from the model: "we never let AI design the website. We always try to um draft what we want it to look like and have some creative direction." And on expectations: "we never oneshot the website. It's it's you can't really do that. It probably takes one to 200 prompts to get a website to look to look good." The mega menu is his example of something painful in Elementor and cheap now, with the added benefit of offering the client several versions. **Media generation.** Higgsfield for video, Google AI Studio for images, replacing stock photography — "we've all seen those template websites where it's like the same three people on every website... the girl smiling with the red sweater." His framing: "It's like if every customer could afford to hire a professional photographer." Client-supplied phone photos get run through Gemini to correct composition and exposure while keeping the photo. **Contact forms.** A specific, familiar failure chain: WordPress default sends via PHP, mail lands in spam or silently fails, you add an SMTP plugin, then "sometimes the PHP updates and the form stops working and then you find out a week later." His replacement is Resend over API with domain verification. **The security argument.** He claims a custom site is "probably more secure than WordPress" for a small business, reasoning: you need not expose a login page at all; every WordPress install has the same login path by default; unpatched plugins and PHP accumulate vulnerabilities; and WordPress's ubiquity makes it a standing bot target. For a static site with no login, "that surface area of of how many things can break um is actually much much smaller." **The central claim.** > [!quote] > most small businesses, they they never really needed WordPress. WordPress was easy for us, the developer, to set it up for them. Um, but the large majority of the businesses that I would set up a website for, they never really figured out how to use WordPress. The website would just sit there. They would break the website. They would make it ugly. His replacement model: build plus paid management, which most clients prefer. For clients who do want to edit, "you can build a custom editor for them that meets them at their skill level and doesn't break the website" — as against WordPress, "where they have access to edit everything and and they can break things." **On Elementor's AI push.** "why would I use AI inside of inside of WordPress and like make it more bulky and slow it down and and when I can just use the the direct AI to code, right, without anything in the middle." **He does not close the door.** "I think there is still a place um for WordPress for some customers. Um it's getting smaller and smaller." And he ends by soliciting counter-cases from the audience. ## 📚 References No external sources, citations, data, or links are offered. Every claim is first-person report from one agency's practice over roughly six months. The tools named — Claude Code, Resend, Higgsfield, Google AI Studio, Stripe, JetEngine, Crocoblocks — are named as things he uses, not as evidence. **Verification note.** Nothing here is independently checkable. The value is in the specificity and internal consistency of the account and in the speaker's stated standing (ex-Elementor, 1,000+ sites), not in corroboration. ## 🗣️ Paraphrase Emanuel ran a site-building agency on WordPress and Elementor for a decade and stopped using both in February. The trigger was watching Claude Code produce, in twenty minutes, a working version of a real-estate site he had scoped as months of work involving a template, custom loops, a custom post type, a map plugin and a search add-on. He started hybrid — generating Elementor templates and custom plugins with Claude while still shipping WordPress — then moved to custom builds. He no longer buys plugins, because a generated one contains only the features he needs instead of a settings panel he has to learn. He built a plugin that lets a Claude session administer a WordPress site directly, and used it to clean two thousand dead products out of a WooCommerce store in minutes. He is careful about scope. Payments go through Stripe. Enterprise work needs an engineer reviewing code. Design does not come from the model — they decide the layout and describe it, and it takes one to two hundred prompts rather than one. His central argument is not that WordPress is bad but that most of his small-business clients never used it. The CMS was convenient for the builder; the client left the site alone, or broke it. He now builds and manages, and where a client wants to edit, he builds a small editor scoped to what they can safely change. ## 📰 Newsletter **"They never really needed WordPress" — an ex-Elementor employee explains why he left** Worth watching if you build sites for small businesses, and worth arguing with. Emanuel — 1,000+ sites, formerly of Elementor — hasn't touched WordPress or Elementor since February. The trigger was watching Claude Code build, in about twenty minutes, a working version of a real-estate site he'd scoped as months of template work, custom loops, a custom post type, a paid map plugin and JetEngine for search. Six months in, he doesn't buy plugins any more. His reasoning isn't cost — it's fit: a purchased real-estate plugin arrives with *"a million settings, default functions"* you must learn before doing anything, where a generated one has only what you need. When he wanted a default placeholder image for listings without photos, he asked, and it existed two seconds later. He's more careful than the genre usually is. Not payment processors. Enterprise needs a real engineer reviewing code. And design doesn't come from the model — *"we never let AI design the website"* — with a realistic number attached: one to two hundred prompts, never one-shot. The claim that should provoke you: *"most small businesses, they never really needed WordPress. WordPress was easy for us, the developer, to set it up for them."* His clients mostly never learned the CMS. The site sat there or got broken. So now he builds, manages it himself, and where a client wants to edit, he ships a small editor scoped to what they can safely touch. Two places to push back. His security comparison puts a static site with no login against an unpatched WordPress with a default login page — best case against worst case. And he mentions, without a flicker of concern, that he built a plugin exposing an API that lets a Claude session log into a client's WordPress and change pages, settings, the shop and other plugins — then *deployed it to every WordPress client he has*. In a video arguing custom sites are more secure, that surface goes entirely unexamined. Read it against Craylor's WordCamp video from yesterday. Craylor argued WordPress narrows to what it's good at: storing and serving data. Emanuel just rebuilt that part too. ## ✅ Action Items #### DevRel - The "who was the CMS actually for" question is the genuinely provocative one and deserves a careful public treatment — his answer is that it served the builder, and that is uncomfortable and possibly right for a segment. - The security comparison needs a fair-terms rebuttal, not a dismissal. Static-versus-unpatched-WordPress is not the comparison; static-versus-maintained-WordPress is. #### OSPO - The admin-API plugin pattern — exposing a site to an agent session — is going to spread. Someone should write the threat model before it does, because he has already shipped it to a client fleet. #### Community - The clients described here are the ones the WordPress community rarely hears from: businesses that got a CMS, never used it, and broke it. That is a real product-fit signal. #### WordPress - **Core** — the editing-permissions point is a live product question: he ships a scoped editor because WordPress gives clients access to everything and they break things. - **Core AI** — his Elementor-AI critique is direct: why run AI inside the CMS when you can run it against the code. Worth answering rather than ignoring. - **Core Performance** — "it's so much easier to get a fast website when it's just clean code without any of the extra bulk." A fair challenge. - **Core Program Team / Mobile / Photos / TV / Polyglots / Openverse / Meta / CLI / Tide** — Not applicable to this source. - **Playground** — a scoped-editor demo is exactly the kind of thing Playground could show. - **Community / Training** — the hybrid path he took first (AI generating Elementor templates and custom plugins) is a more approachable on-ramp than the full migration, and nobody teaches it. - **Marketing** — the "never really needed WordPress" claim is the strongest public criticism of the small-business value proposition in a while. - **Support** — the PHP-mail failure chain he describes is a recurring real support burden. - **Design** — his anti-slop practice (decide the design, then describe it) is a usable teaching frame. - **Documentation** — Not applicable to this source. - **Accessibility** — **unexamined and important**: a hand-built custom site has no theme-review or accessibility-ready baseline behind it, and neither he nor the video mentions accessibility once. - **Hosting** — the shift from managed WordPress to static plus APIs has direct hosting implications. - **Plugins** — the sharpest commercial signal in the video: an agency that bought plugins now generates them, and says so. #### The WPOCC - Pair with the plugin-economics thread. This is a first-hand account of an agency exiting the paid-plugin market entirely. ### FAIR - Indirect. His clients' independence now rests on his agency rather than on a portable CMS, which is a different dependency and not obviously a better one for the client. ## 🧪 Hypotheses 1. **Most small-business WordPress installs are never edited by the client after handoff.** Test: sample agency-built sites and measure client-initiated content edits at 3, 6 and 12 months. This is his central premise and it is directly measurable. 2. **A scoped custom editor produces fewer client-caused breakages than wp-admin.** Test: compare support tickets categorised as client error across both models. 3. **Custom static sites for small business have a lower incident rate than maintained WordPress installs** — his claim, on fair terms rather than against unpatched installs. Test: compare like-for-like maintained sites. 4. **The admin-API plugin is a material new attack surface.** Test: threat-model it — credential storage, scope of the API, revocation, audit logging, blast radius across a client fleet. 5. **Generated plugins accumulate maintenance cost that shows up later.** Test: revisit at 18–24 months and count how many still work through PHP and dependency upgrades. 6. **Accessibility outcomes are worse on hand-built custom sites** than on theme-based WordPress. Test: run automated audits across both samples. ## 📊 Methodology **What this is.** Single-practitioner testimony over roughly six months, from someone with unusually relevant standing (ex-Elementor, 1,000+ sites). No measurement, no comparison group, no data. **What it supports well.** That this workflow is viable for one agency serving small businesses, and that the specific frictions he names — plugin settings overhead, PHP mail delivery, mega menus, Elementor iteration cost — were real enough to drive a practice change by someone with a decade of investment in the old way. **What it does not support.** Any general claim about WordPress, security, or performance. His comparisons are recollections of his own experience, and the security comparison in particular is between unlike cases. **Selection effects worth naming.** His client base is small businesses who never learned the CMS. Clients who *did* adopt WordPress successfully are, by construction, not in his sample of frustration. That does not refute his claim about his segment; it bounds it. **One methodological strength.** He distinguishes the demo from the practice. The 20-minute build was the trigger, not the evidence; the evidence is six months of shipped work, and he presents it that way. ## ❓ Questions - What is in the admin-API plugin? How is the credential scoped, stored, rotated and revoked, and what does it log? - How do the generated plugins fare across PHP version upgrades in a year? Nobody has reached that horizon yet. - What happens to a client if the agency relationship ends? WordPress is portable to another agency; is a bespoke stack plus a custom editor? - What is the accessibility baseline of the generated sites? It is not mentioned once. - How many of the 1,000+ prior sites have actually been migrated versus described as candidates? - What does the custom editor look like, and how much does building one cost per client? - Would the same clients have been better served by managed WordPress with a locked-down role, which is a thing that exists? ## 🔮 Future Research - **Measure the never-edited premise.** It is the load-bearing claim and it is straightforwardly checkable across any agency's portfolio. - **Threat-model agent-administration plugins** before the pattern becomes common; the credential and blast-radius questions are the urgent ones. - **Longitudinal maintenance study** of generated plugins across PHP upgrades. - **Accessibility comparison** between hand-built AI-generated sites and theme-based WordPress builds. - **Client-portability analysis**: what exit looks like from a bespoke stack versus from WordPress. ## 💡 Implications **Practice.** The transferable technique is not "stop using WordPress" — it is **build the editing surface to the client's actual skill level** rather than handing over an admin panel that can break the site. That insight survives regardless of what generates the front end. **Policy.** For agencies, the plugin-purchasing decision has changed shape: the question is now fit versus maintenance liability, not build versus buy on cost. Generated code you own is also generated code you maintain. **Security.** Two things, pulling opposite ways. Reducing surface by removing a login is a real and correct instinct. Shipping an agent-accessible admin API across a client fleet is a large new surface, and it appears in the same video without comment. The net is unassessed, and the video treats only the favourable half. **Education.** The hybrid stage he passed through — AI generating Elementor templates and custom plugins while still on WordPress — is the practical on-ramp, and it is missing from both the pro-WordPress and anti-WordPress material. **Funding.** An agency that bought plugins and paid for software now generates both. If that generalises even partially, the commercial plugin layer that funds a lot of WordPress maintenance is exposed — which is exactly the flatlined-sales signal reported from WordCamp US this week. ## 🧠 Learning Styles Assessment **Reading level:** ~Grade 9 spoken, conversational and heavily hedged with filler. Assumes familiarity with WordPress, Elementor, custom post types and the plugin ecosystem. #### 👀 Visual learners Poorly served in this capture — it is a talking-head video and the transcript loses whatever was shown. Notably, he describes a Zillow-like result and no screenshot survives here. #### 🔊 Aural learners Best served. Conversational and unscripted. #### 🗣️ Verbal learners Well served by one line: "most small businesses, they never really needed WordPress." #### 🧩 Kinesthetic learners Moderately served. The workflow is described concretely, but no steps, prompts, or code are shown. #### 🧠 Logical learners Adequately served. The argument is sequential and honest about scope, though the security section does not hold together. #### 🧑‍🤝‍🧑 Social learners Well served. It is framed as a conversation, credits Tyler for the demo, and ends by soliciting counter-cases. #### 🧘‍♀️ Solitary learners Well served — self-contained, 18 minutes. #### 🌿 Naturalistic learners Not applicable to this source. ## 📊 Accessibility Assessment Assessed as delivered: an 18-minute YouTube talking-head video. #### Screen reader semantics Not applicable to the video; the caption track carries no structure. #### Keyboard navigation Governed by the YouTube player, which is keyboard operable. #### Contrast and readability Not assessable from the transcript. #### Text resizing and reflow Not applicable to video. #### Media and captions **Auto-captions only** as far as the capture shows, and their quality is visibly poor — "Clawude", "Chad GPT", "croco blocks", "element pages". Auto-captions do not satisfy **WCAG 1.2.2 (Captions, A)**, which requires accuracy, and mangled tool names are exactly the failure that matters for a technical audience. No audio description; for a talking-head video that is a smaller loss than for a visual explainer. #### Forms and interactions Not applicable to this source. #### Standards reference WCAG 2.2 Level AA. One clear Level A gap (accurate captions). **Worth flagging as substance, not just form:** the video advocates hand-built custom sites and never mentions accessibility once — no theme-review baseline, no automated checks, no WCAG reference. That is a gap in the *argument*, not only in the artifact. ## 🌍 DEIB Assessment #### Cultural breadth Narrow: US/English small-business web design. No claim beyond it. #### Inclusive language Neutral and notably generous. He does not disparage WordPress, Elementor (his former employer), or clients who break their sites — the framing is that the tool was mismatched, not that users were foolish. #### Neurodiversity support Mixed. Conversational and repetitive, which helps some listeners and makes the structure hard to skim. No chapters or headings in the capture. #### Representation **The clients are described and never heard.** The whole argument rests on what small-business owners did and did not do with their sites, and not one of them speaks. His custom-editor solution is designed for people whose needs are characterised entirely by the person selling to them. #### Psychological safety Good. He admits a prior misconception plainly ("my understanding... was that cloud code was like an engineering tool"), credits Tyler for changing his mind, and invites disagreement at the end rather than closing the case. ## ✅ Logical Validity #### Strong reasoning - **He distinguishes the demo from the evidence.** The 20-minute build changed his mind; six months of shipped work is what he offers as support. That is the right ordering and most of this genre gets it backwards. - **Scope is bounded unprompted and against interest** — not payment processors, enterprise needs engineer review, never one-shot, 100–200 prompts. Each concession costs him rhetorical ground and he makes them anyway. - **The plugin-fit argument is well-mechanised.** Purchased plugins carry configuration overhead proportional to their generality; a bespoke one carries none. That is a real property, not a preference. - **The central claim is falsifiable and stated as a claim.** "They never really figured out how to use WordPress" can be measured. #### Fallacies - **Not-like-for-like comparison, load-bearing.** The security argument sets a static site with no login against a WordPress install with unpatched plugins, unpatched PHP and a default login path. The fair comparison is against a maintained install. **Fix:** compare maintained-to-maintained; the surface-area point survives, the conclusion narrows. - **The unexamined counter-instance.** He ships a plugin granting an AI session admin access to client WordPress sites, fleet-wide, in the same video arguing custom sites are more secure. This is not merely an omission — it is evidence against his own thesis, present in his own account, unaddressed. **Fix:** threat-model it out loud. - **Selection effect in the central claim.** His sample is clients who never learned WordPress; clients who did are absent by construction. **Fix:** state the segment; the claim is probably right *for it*. - **Survivorship in the six-month record.** Sites that worked are described; failures, rework and abandoned attempts are not mentioned. Six months is also short of the first real PHP-upgrade cycle. **Fix:** report the misses. - **Equivocation on "more secure."** He slides between fewer-vulnerabilities-by-surface and less-targeted-by-bots. Both are real, they are different claims, and the second is a function of WordPress's market share rather than of code quality. #### Tone of voice Measured, hedged, non-triumphal. He repeatedly qualifies ("I think", "probably", "for a very small business"), credits others, and declines to declare WordPress finished — "there is still a place for WordPress for some customers. It's getting smaller and smaller." For a video titled *Why I'm Moving All My Clients Off Elementor*, the content is markedly less absolute than the title. ## 🛡️ DARVO Analysis **Deny** — none. He does not deny WordPress's strengths and repeatedly grants them, including that his team achieved good WordPress performance previously. **Attack** — mild and directed at tools rather than people. Elementor's AI push gets a pointed question; his former employer is otherwise treated respectfully. **Reverse victim and offender** — none. He does not position himself as wronged by WordPress, and he takes responsibility for the prior model rather than blaming clients for not using it: "WordPress was easy for us, the developer." **Assessment: DARVO absent.** Notable because a departure narrative from a former employee is the natural place for it, and the account is conspicuously free of grievance. ## 🎯 Conclusion **Bottom line.** An ex-Elementor practitioner with a thousand sites behind him stopped using WordPress in February and has six months of production work supporting the change. His strongest argument is not about AI at all: **the CMS was convenient for the builder, and most of his small-business clients never used it** — so once building becomes cheap, the client-facing justification thins. That is measurable, and it is more interesting than the tooling story. **Where the argument fails** is security. The comparison is best-case-custom against worst-case-WordPress, and — more damagingly — he reports shipping an agent-accessible administrative API across his entire WordPress client fleet without a word about its risk, in the same segment where he argues custom sites are safer. That is a counter-instance in his own testimony. **Read against yesterday's WordCamp video**, the two agree on the direction and disagree on the floor. Craylor argued WordPress narrows to storing and serving data. Emanuel rebuilt that layer too, with a custom post type plugin and a scoped editor. If both are right, the defensible core is smaller than either says alone. **Next steps.** 1. Test the never-edited premise against a real portfolio — it is the load-bearing claim and it is cheap to check. 2. Threat-model the agent-administration plugin pattern before it spreads, because he has already deployed it fleet-wide. 3. Revisit at 18 months on generated-plugin maintenance across a PHP upgrade cycle. ## 🔄 Refactor Appendix — Why I'm Moving All My Clients Off Elementor ### 📚 Literature Atoms (H3) #### [H1] The CMS served the builder, not the client > [!quote] ID:rw_eman_needed > most small businesses, they they never really needed WordPress. WordPress was easy for us, the developer, to set it up for them. **Context & use**: - ~15:48, after the security section, as the summary of six months' practice. - The central and most falsifiable claim in the video. It relocates the justification for a CMS from the client's needs to the builder's convenience, and it is measurable by looking at post-handoff edit activity. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Purchased generality costs configuration effort > [!quote] ID:rw_eman_plugins > if you purchase uh like a real estate um post type plugin, it's going to come with a million settings, default functions. Um you have to spend so much energy learning how to set up and and use the plugin before doing anything. **Context & use**: - ~05:46, explaining why he stopped buying plugins. - The argument is fit, not cost: a general product carries configuration overhead proportional to its generality, and bespoke code carries none — traded against maintenance he now owns. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H3] An agent was given fleet-wide admin access without a threat model > [!quote] ID:rw_eman_api > the plug-in basically generates an API for your WordPress website and you put that API into your cloud session and uh it can just claude can log into your WordPress website. It can make changes to the pages to the element pages to the shop to the settings other plugins Yoast whatever the case may be. **Context & use**: - ~08:26, presented purely as a capability win, followed by the 2,000-product WooCommerce cleanup. - He states he "added it to all the customers that I had that had WordPress." Recorded as a **counter-instance to his own security thesis**, which appears seven minutes later in the same video. **Tags**: #xref #bmf <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] A Tool Chosen for the Builder's Convenience Is Justified by the Wrong Party's Needs **Claim** (one sentence, Courtney's voice): When the party selecting a tool is not the party who must live with it, the selection optimises for setup cost rather than for use, and the resulting capability goes unused while its complexity is still paid for. **Evidence pointer**: [[#H1]], plus the described outcome — clients who "never really figured out how to use WordPress," whose sites "would just sit there" or got broken — and his replacement, a scoped editor "that meets them at their skill level." **Scope & conditions**: Holds wherever selection and use are separated — agencies choosing client platforms, IT choosing staff tooling, architects choosing frameworks for teams they leave. Breaks where the selector also operates the tool long-term, which realigns the incentive. **The remedy is not a simpler tool but a narrower surface**: he did not give clients an easier CMS, he gave them an editor scoped to what they could safely change. Does not follow that the original choice was wrong at the time — setup cost is a real constraint; it follows that it should be named as whose constraint it was. **Links** (≥1 with annotation): - [[3. Resources/Permanent Notes/Visible Interface Text Beats Hover-Dependent Explanation]] — because applies-in: both are about designing to the actual user's capability rather than to the builder's mental model - [[3. Resources/Permanent Notes/A Capability Demonstration Is Not an Operating Model]] — because contrasts, and he passes the test: the 20-minute demo changed his mind, and six months of production work is what he offers as evidence - [[3. Resources/Permanent Notes/Interface Surface Area Costs Selection Accuracy Not Just Tokens]] — because extends: the same surface-area cost measured in human configuration effort rather than model tokens - [[3. Resources/Readwise/Articles/Is WordPress DYING I Went to WordCamp US to Find Out]] — because contrasts: Craylor argues WordPress narrows to storing and serving data, and this account rebuilds that layer too, so the two together bound the defensible core lower than either does alone `proof_state: working` <!-- atomicity: 1 idea ✓ --> #### [P2] Already captured — connect, do not create The agent-administration surface [[#H3]] belongs against [[3. Resources/Permanent Notes/Exfiltration Needs Three Capabilities Together Not Any One of Them]] rather than as a new note: an API granting a model session admin access to a live site supplies private data access and an outbound channel in one move, and any untrusted content the agent reads completes the trifecta. This is that conjunction being deployed to a client fleet by someone who does not appear to have modelled it. The plugin-economics signal belongs against the flatlined indie plugin sales reported from WordCamp US — an agency exiting the paid-plugin market is the demand-side account of the same phenomenon. ### ✏️ Fleeting Queue - [F1] Measure the never-edited premise: client-initiated edits at 3/6/12 months post-handoff across an agency portfolio. #fleeting #inbox - [F2] Threat-model the agent-admin-API plugin pattern — credential scope, storage, rotation, revocation, audit, blast radius. Write before it spreads. #fleeting #inbox - [F3] Accessibility baseline of AI-generated custom sites versus theme-based WordPress. Not mentioned once in 18 minutes. #fleeting #inbox - [F4] What does client exit look like from a bespoke stack? WordPress is portable to another agency; is this? #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft the agent-admin-API threat model as a public note — context: Emanuel's WordPress plugin, deployed fleet-wide #things - [ ] Pull post-handoff edit stats from any agency willing to share, to test the never-edited claim — context: Elementor video #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Why I'm Moving All My Clients Off Elementor.md|Why I'm Moving All My Clients Off Elementor by Emanuel (I Create Your Site)]] ## Highlights - [00:07:53] complex like payment processors and things like that we always use like an API we do it through Stripe or something like that we we'll never like vibe code that of course um But but yeah, it was uh it was incredible. Um we published their website um and then they wanted updates and then the next thing I built was a plugin because at that point I was like okay I want to like avoid WordPress. I want to just like see how much I can just do through Claude. Um, I created a plugin that uh talks it ba the plug-in basically generates an API for your WordPress website and you put that ([View Highlight](https://read.readwise.io/read/01m17gk8reqw6zway080veyyhf)) - Note: [H2] He built a plugin giving a Claude session admin access to WordPress — pages, Elementor pages, shop, settings, other plugins, Yoast — and says he "added it to all the customers that I had that had WordPress." Presented purely as a capability win. This is a COUNTER-INSTANCE to his own security thesis, which arrives seven minutes later in the same video. Supplies private data access plus an outbound channel in one move; any untrusted content the agent reads completes the Lethal Trifecta. - Tags: counter-instance, atom/literature/h2 - [00:15:48] businesses, they they never really needed WordPress. WordPress was easy for us, the developer, to set it up for them. Um, but the large majority of the businesses that I would set up a website for, they never really figured out how to use WordPress. The website would just sit there. They would break the website. They would make it ugly. They would mess it up. Um, the way we're working now, we develop the website and we offer management for it as well. Um, and most businesses are happy to pay for that because they they don't want to mess with the website. And even for clients that do want to edit the website ([View Highlight](https://read.readwise.io/read/01m17gjwpqzegk16w3yx1p5na2)) - Note: [H1] The CMS served the builder, not the client — the central and most falsifiable claim in the video. Relocates the justification for a CMS from the client's needs to the builder's convenience, and it is measurable: count client-initiated edits at 3/6/12 months post-handoff. Note the selection effect though — his sample is clients who never learned it; those who did are absent by construction. - Tags: atom/literature/h1