The default experiment looks reasonable. You already have WordPress or Squarespace. Content is hard. Layout is fiddly. So you put AI into the CMS: a sidebar that drafts posts, a block that rewrites headlines, a plugin that claims to “operate Elementor for you.” Sometimes you get further — generate HTML offline, paste it into a custom theme, upload a blog post as a file. It sort of works. It also feels like pushing a rope.

The clicking is still the slow part. The AI still has to speak a vocabulary invented for humans who could not safely touch the web substrate. And every time someone tries to drive a serious page builder from outside wp-admin, they discover that the machine is not editing the site. It is tunnelling through a representation designed for fingers.

That is not a temporary tooling gap. It is a category boundary moving.

The future website is not built for a business owner to administer. It is built for the business owner’s AI to operate.

Most commentary stops at a softer claim: “WordPress and Squarespace are legacy.” True as atmosphere, weak as analysis. A CMS was never one product. It fused two jobs that AI treats differently: a translation layer for humans who could not operate HTML, CSS, hosting and databases; and an operational and integration control plane for publishing, roles, forms, payments and plugins. AI does not modernise that fusion. It dissolves the first job and forces the second to unbundle.

That is the thesis this book owns as CMS Unbundling.

The reader question

Why does putting AI into WordPress keep failing — structurally, not just “the plugin is early”? And what architecture actually replaces the CMS, including its plugins, when the owner’s AI does the operating?

After this book you should be able to do four things without me in the room:

1. Run the two-job decomposition on any CMS-shaped platform — what is translation, what is durable state.
2. Place a site on the transaction-depth spectrum and decide remove versus retain.
3. Specify the Post-CMS Stack with its deterministic shell, so you do not replace the CMS with FTP and a chatbot.
4. Build integrations by decompiling the plugin corpus into verified invariants instead of installing or copying a plugin.

Two movements, one argument

The book has two movements. They are not two essays stapled together.

Movement one unbundles the CMS: two-job decomposition, the compiler-between-compilers absurdity, design-time AI with a deterministic runtime, the transaction-depth boundary, and the invisible-guarantees test. It ends with a question it cannot answer alone. If the CMS goes, what replaces the plugin ecosystem that made WordPress valuable as a platform?

Movement two is the answer: Ecosystem Decompilation. A plugin is a fossilised integration investigation. You never copy one — that imports a compiled North Star. You read several independent implementations, let convergence separate invariants from local choice, verify every candidate against the live provider contract, and generate the narrow adapter the business actually needs. The corpus is evidence, never authority.

Hold this much from the start: losing install-and-run convenience is real. Losing the learning encoded in tens of thousands of plugins is optional — and AI is what makes that learning mineable without adopting WordPress as your operating system.

The sharpest one-sentence version, for the wall:

AI does not make the CMS smarter; it unbundles it. Conversation replaces the editor, Git and tests replace the opaque content representation, and commodity APIs replace the plugin bazaar.

Chapter 2 mints the mechanism underneath that sentence: two jobs, fused in every CMS you have ever used, unbundled by the same shift that makes an owner’s AI a better operator than a click interface.

Name the mechanism before the anecdotes. Everything later in this book is an application of one decomposition.

Job one: the human translation layer

For most of the web’s commercial life, the business expert could not safely operate the substrate. HTML was easy to break. CSS was a craft. Hosting and databases were someone else’s problem. So the industry built click interfaces: forms, blocks, themes, page builders. The human pointed. The CMS compiled pointing into files, rows and rendered pages.

That job was always a translation. Intent went in as menus and drag-handles. Artefacts came out as HTML, CSS, media references and layout state. The value was real. So was the cost: every change had to be expressible in the builder’s ontology. If Elementor or Gutenberg or Squarespace did not have a first-class concept for what you wanted, you hired someone to fake it inside their concepts.

AI changes the economics of job one. An intention compiler can take “make the hero less corporate and put the new service on its own page” and produce source files, tests and a deployable artefact without the human learning block schemas. The click interface does not become smarter. It becomes an extra translation step — intent into AI instructions into CMS representation into theme representation into HTML — when the middle was only there because the human could not write the ends.

That is AI as Interface applied to websites: intention replaces menus and navigation as the primary interaction surface between the expert and the system.

Job two: the operational and integration control plane

The second job is why people still defend the CMS after the editor feels obsolete. Websites do not only display copy. They publish, permission, redirect, accept forms, fight spam, take payments, sync contacts, schedule bookings, emit analytics events and keep secrets out of the public tree. WordPress did not become a platform because the block editor was beautiful. It became a platform because a shared runtime could host a plugin that made one of those problems “someone else’s install button.”

AI does not make job two disappear. Payments still need settlement. CRM still needs fields and lifecycle. Auth still needs a boundary. What changes is whether job two must live inside the same product that was invented for job one. It does not. Job two can unbundle into:

• a small deterministic control plane — auth, tests, diff, approval, deploy, logs, rollback; and
• commodity services — Stripe, email providers, CRM APIs, identity, booking engines, analytics — joined by narrow adapters you own.

The definitive split

Two paths

The path the CMS trained the industry on:

Business expert
  → marketer or web developer
  → CMS concepts
  → theme or block representation
  → rendered website

The path that becomes available when the translation layer is optional:

Business expert
  → conversational and visual AI
  → source artefact
  → test
  → deploy

The expert moves closer to the coalface. There is no specialist required to re-express intent in Elementor vocabulary before anything can ship. The AI is the thin shim — hands, eyes and technical execution — not another human layer with its own ticket queue.

If you only remember one thing from doctrine: the CMS is not “legacy software” in the vague sense. It is a fusion product whose primary job met a better compiler. Everything that feels like thrashing when you put AI into WordPress is you trying to preserve the fusion after the reason for it has gone.

Chapter 3 draws the absurdity that fusion creates when AI is already in the loop: a compiler between two compilers.

Call a CMS what it was: a compiler for people who could not — or should not — manipulate HTML, CSS, JavaScript, PHP, hosting and databases by hand. That is not an insult. Compilers exist so humans can work at a safer level of abstraction. Themes, blocks and page builders were the IR. Rendered pages were the object code. Millions of useful sites shipped that way.

AI is now an intention compiler for the same substrate. The human’s job moves from execution to direction and judgment: say what should be true, inspect the artefact, accept or reject. Production capacity is no longer the binding constraint; quality of intent is.

So what happens when you keep the old compiler in the middle?

Human intention
  → AI-generated instructions
  → CMS representation
  → theme / block representation
  → HTML

That stack is ridiculous. The AI already could have written the HTML or PHP. Instead it must reverse-engineer a block schema, manipulate database records, discover the right REST endpoint, operate wp-admin, or write a custom plugin whose only purpose is to expose a human abstraction to a machine that did not need the abstraction.

Every hour spent teaching a model to “use Elementor properly” is an hour spent reconstructing a compiler pass that existed solely because the previous operator was human. The model is not human. Forcing it to act like one is not compatibility. It is cosplay with production side effects.

What reverse-engineering actually costs

When the AI is forced to drive a CMS, the work is not “writing the homepage.” The work is archaeology:

• discover which REST fields are real source versus rendered exhaust;
• map block or widget schemas that were never designed as a public API;
• mutate database rows that themes and caches assume they alone own;
• recover from partial updates when the builder’s client-side state disagrees with the server;
• maintain a private plugin simply to expose what should have been files.

That labour is pure tax. It exists only because the intermediate representation was optimised for human pointing. An intention compiler does not need that IR. Paying the tax is a choice disguised as compatibility.

The expert moves closer to the coalface

Unbundling is not only an architecture story. It is a labour story. The old chain put specialists between the person who knew the business and the deployed artefact: marketer, web developer, CMS administrator, sometimes an agency. Each hop re-encoded intent. Each hop lost fidelity and added calendar time.

When conversation becomes the admin interface and source files become the content store, the expert can describe the homepage, paste the wording, specify the image crop, and see a diff. The representational intermediaries collapse. That is the commercial meaning of the compiler shift: fewer people translating, more time judging.

If your AI spends its tokens navigating a page builder, you chose the wrong intermediate representation.

Chapter 5 will run the same intent through two architectures and show the difference as a negative result and a partial positive one. First, Chapter 4 places AI on the right side of another boundary: design-time versus runtime. The Post-CMS Stack is not an AI that rewrites the page on every visitor request. It is an AI that produces boring, fast, deterministic software the visitor never has to negotiate with.

There is a subtlety that separates a post-CMS architecture from the demo that impresses a marketing standup: when consequence occurs relative to review.

Design-time AI produces an inspectable artefact — code, content files, configuration, a diff, a test report — before that artefact affects the world. Existing review, versioning, testing, approval and rollback systems can govern what advances. Runtime AI participates in production consequence: its output informs or triggers a live response before it becomes a fully reviewable artefact. Consequential runtime use needs purpose-built containment. Design-time use can borrow twenty years of software hygiene.

CMS Unbundling sits almost entirely on the design-time side. The owner says what should change. The AI edits, renders, inspects, tests and proposes. Ordinary code deploys. The visitor receives static HTML or generated output, small form endpoints, CDN caching — and no model call when they open a page.

What the owner interface actually does

AI appears primarily in production verbs, not visitor journeys:

• “Replace this paragraph with this wording.”
• “Make the hero less corporate.”
• “Use this photograph and crop it around the person.”
• “Add a page explaining the new service.”
• “This form should create a HubSpot contact and notify the office manager.”
• “Show me what changed.”
• “Undo yesterday’s version.”

The resulting artefact is conventional software. That is safer and more economical than putting an AI chatbot into every visitor interaction — and it is deliberately out of scope for this book to argue otherwise. Runtime personalisation and public chatbots are a different product class with different governance burden.

The Post-CMS Stack

The successor is not “a website generated once by AI.” That is AI-assisted web development — useful, not a category. The successor is an agent-operable website control plane:

Business owner or expert
          ↓
Conversational + visual AI interface
          ↓
Git-native content, design rules and source files
          ↓
Deterministic control plane
auth · permissions · tests · diff · approval · deploy · logs · rollback
          ↓
Static site + small dynamic endpoints
          ↓
Commodity services
payments · email · CRM · identity · booking · analytics

That diagram is load-bearing for the rest of the book. Later chapters specialise rows of it; they do not replace it.

The acceptance test

For every layer, ask: can the agent code, test, deploy and diagnose it? A layer the agent cannot run, verify, ship and read the logs of by itself is not done. The enemy is not PHP or HTML. The enemy is a representation trapped behind a human-only interface.

That aligns with agent addressability: a visual UI is not a proper machine-operation surface. An agent needs legible state, authorised actions, consequences and observable change — not pixels and simulated fingers.

When the agent becomes the high-frequency customer of the site’s production surface, UI polish on the admin theme stops being the moat. The competitive surface is how safely, predictably and observably an authorised intelligence can change the artefact.

Why runtime AI is the wrong substitute for unbundling

When teams feel the CMS is failing, a common pivot is to add a visitor-facing chatbot or generative page personalisation and call the site modern. That moves intelligence into the runtime path: every session can become a model call, every answer a stochastic event, every incident a prompt-forensics problem. Unbundling does the opposite. It puts AI where review is cheap — owner production — and keeps the public artefact boring. If you need conversational UX for customers, that is a separate product decision with runtime governance. It is not the CMS replacement this book specifies.

Chapter 5 puts the same intent through two architectures — a page-builder tunnel and a Git-native conversation — so the stack stops being a diagram and becomes a result.

Doctrine is cheap until you run the same intent through two machines. The intent class is simple: an owner or operator wants the site changed — copy, layout, a section, a recovery path — without sitting in wp-admin. I have run both architectures myself. One is a negative result. The other is a partial positive that also reveals the next engineering step.

Hold the intent fixed while the intermediate representation changes. That is the only way to see which failure is a bad afternoon and which failure is structural.

Architecture A: the Elementor tunnel

The experiment ran against a dental practice’s WordPress site built with Elementor. The operational question was narrow: can an external program change text inside an Elementor-built page without relying on the human admin UI?

Elementor renders a page for visitors as HTML. Its editable layout, however, lives as a large JSON value under the _elementor_data post-meta key. That split is not an accident of one install. It is how editor-owned state works: the public page is a compiled artefact; the builder document is the source of truth, stored where the human product put it — inside WordPress post meta, shaped for Elementor’s own client, not for an external agent.

What actually travelled on the stock path

The first half of the work tested whether that source representation could be reached through the site’s existing REST surface. Ordinary page endpoints, edit context, revisions, returned meta fields, and alternate paths that looked promising on paper were all tried.

What those stock endpoints actually returned: rendered Elementor HTML — widget markup, the visible headline, the page as a visitor would see it. They did not expose the editable _elementor_data blob on that installation. Scraping the heading would locate visible text. It would not provide the page-builder document Elementor itself edits.

So if an agent “reads the page” through the normal API, what travels over the wire is exhaust: compiled markup. What does not travel is the hierarchical JSON of sections, widgets, settings and nested structures that a real edit must mutate. Guessing from HTML which widget owns which string is reverse-engineering a compiler output. That is why the negative result is structural, not a bad afternoon with flaky network. Editor-owned state lived behind a human product surface. The public contract returned the brochure, not the manuscript.

What the private tunnel then had to carry

The spike stopped trying to infer structure from HTML and built a private seam: a WordPress plugin registering routes under elementor-remote/v1 — get-nonce, ping, read, patch, restore — that accessed _elementor_data directly in wp_postmeta through $wpdb.

Over that path, what travelled was different:

• Read: the full stored JSON document for a post id — the real editor state, not the visitor HTML.
• Patch: search and replace strings applied with raw str_replace over that JSON text, not a typed Elementor editing API.
• Backup: a file snapshot of post id, timestamp and original value before mutation.
• Restore: write the saved value back to the same post-meta row.

Call that architecture by its real name: conversation → custom tunnel → database-backed JSON blob → hope Elementor still understands the result.

Hope is doing real work here. A blind textual replace can break nesting, leave invalid JSON, desynchronise Elementor caches, or produce a document the builder opens but cannot reliably re-save. The tunnel proves the operational shape of escaping wp-admin. It does not prove a safe AI-native content system.

This is not an AI-native editing surface. It is a machine tunnelling through a human abstraction. Every “AI that drives WordPress” product that still bottoms out in page-builder meta is in this family, whether or not the demo is prettier.

Architecture B: Our Perfect Employee

Our Perfect Employee is a production marketing site whose owner interface is a request box. After authentication, ordinary PHP pulls the repository, launches Claude Code against a separate checkout with a site-specific instruction file, captures the diff, then commits, pushes and deploys when changes are detected. Uploads and Git-history rollback sit beside the same control flow.

What actually travels on this path

The representation is the opposite of Elementor’s blob. Content and layout live in small Git-addressable PHP files under a modular sections/ layout. When the owner types a request, what moves through the system is:

1. an authenticated natural-language instruction;
2. a worker invocation against a server-side checkout (not the live document root as the edit workspace);
3. file-level reads and writes to paths the project instructions describe;
4. a git diff of the working tree;
5. commit and push of detected changes;
6. a deploy script that copies publishable files into the public tree while excluding Git metadata, agent instructions and editor tooling.

The repository is the content store. The conversation is the admin interface. Claude changes files; ordinary code owns synchronisation, versioning, deployment and undo. There is no reverse-engineering of a proprietary builder document because the intermediate representation is source an agent can already operate.

Owner request (natural language)
  → Claude Code edits small Git PHP files
  → git diff (visible receipt)
  → commit / push
  → deterministic deploy script
  → live static-ish site

Same intent class as the Elementor experiment: change the site without sitting in a human-only editor. Different intermediate representation: source files an agent can read and write with ordinary tools, not a proprietary JSON document buried behind rendered HTML.

Honest limits of Our Perfect Employee

A proof that only shows the happy path is marketing. The useful proof includes the debt — and names what still has to be engineered.

Prompt-enforced file boundary, not a hard sandbox. Project instructions told the worker to edit only certain paths (for example index.php and sections/). The invocation still used a permissions-skipping mode. That means the boundary is behavioural: the model is asked to stay inside the fence. It is not a kernel-enforced allowlist that makes out-of-scope writes impossible. For a demo that is tempting. For production authority it is incomplete. The next engineering step is ordinary-code path policy — the shell refuses writes outside the tree, regardless of what the model proposes.

Diff as receipt, not gate. The UI shows Claude’s response and the git diff after the worker exits. That is valuable observability. It is not an independent pre-production gate. Detected changes were committed, pushed and deployed automatically. A human could see what shipped; they were not required to accept the diff before live. The vocabulary shift matters: a receipt proves what happened; a gate decides whether it may happen. Design-time AI earns its governance advantage only when the artefact can be rejected before consequence. Auto-deploy collapses that window.

Other residual gaps. Subprocess outcomes were not validated end-to-end as a complete trust boundary. The public site and the edit checkout were separated operationally — a real improvement over editing production files in place — but separation without a promotion gate is still a fast path from proposal to visitor-visible change.

Those limits are not reasons to return to Elementor. They are why the positive path is a category signal and still incomplete engineering.

Side by side

The enemy is not PHP or HTML. The enemy is a representation trapped behind a human-only interface.

Both architectures are incomplete. Only one incompleteness points forward. The Elementor path will keep inventing better tunnels because the editable state remains owned by a human editor product. The Git-native path needs a harder shell — Chapter 7 — and a rule for when you should not leave transactional engines at all — Chapter 6. The head-to-head does not say “files always win.” It says: if the intent is to let the owner’s AI operate the site, the intermediate representation must be agent-addressable by construction, not by a private plugin that reaches under the floorboards of a page builder.

WordPress is not merely a writing tool. It accumulated a plugin economy because websites often need payments, product catalogues, carts and orders, stock, tax and shipping, user accounts, subscriptions, bookings, CRM synchronisation, forms and spam protection, analytics and consent, redirects, canonicals and SEO metadata. Pretending all of that is “just content” is how people announce a rebuild and then rediscover ecommerce in month four.

The better rule is already in the two-job decomposition:

Remove the CMS where it is translating intention. Retain or buy the systems that are carrying durable operational state and commodity risk.

That is Composable Bespoke applied specifically to websites: buy infrastructure that benefits from scale; generate the application layer that needs to fit the business. Buy the capability; own the join.

The four-tier spectrum

Walk each tier

Brochure — apply remove/retain

Most small business sites live here: a few pages, a contact form, an address, some trust signals. Run the two jobs explicitly.

Translation layer (remove): page builder, theme options, media library as the only content store, SEO plugin panels that only exist because the CMS needs a screen. Replace with Git-native source, conversation for edits, static or generated output.

Operational state (retain or replace narrowly): form-to-email, spam control, analytics tags, redirects. These are not a reason to keep WordPress. They are one or two explicit endpoints and commodity services (email provider, first-party analytics, a redirect map in config).

Reader placement test: if the deepest durable write after a visitor acts is “send an email” or “store a message for staff,” you are brochure-tier. Post-CMS fit is excellent. The migration risk is not commerce; it is forgetting invisible guarantees (Chapter 7) and treating the old site as mood board instead of oracle (Chapter 8).

Lead-generation — apply remove/retain

Service businesses add friction at intake: multi-step forms, CRM fields, notify the office manager, spam controls, maybe a calendar deep-link.

Translation layer (remove): still the builder and theme. Marketing pages do not need a CMS runtime.

Operational state (retain as services, own the joins): CRM (HubSpot or equivalent), email, spam, notification. Do not rebuild HubSpot because a form exists. Do not keep WordPress because HubSpot has a plugin. Extract fields, lifecycle stages and workflows as the implicit specification; keep the CRM until the join is proven; then decide whether any CRM surface can shrink.

Reader placement test: list every field that lands in a system of record after submit. If those systems are CRM/email and not orders or inventory, you are lead-gen. Post-CMS is still excellent — the work is adapter quality, not platform loyalty.

Booking and membership — apply remove/retain

A dental clinic booking project is the hybrid illustration. Patients need a clear journey, copy that matches the practice, and a reliable way to request or hold time. The practice also needs real appointment state, staff calendars, cancellation rules and often deposits.

Translation / experience layer (own and unbundle): marketing pages, service explanations, the public booking journey chrome. Page builders wrapped around booking widgets are still job one. Replace them with an agent-operable experience site.

Transactional backend (retain): practice-management or specialised booking engine that already encodes slots, staff, clinical or membership rules, and liability-adjacent workflows. Deposits may use Stripe as commodity payments (Chapter 12) without rebuilding the schedule core.

Reader placement test: if double-booking, staff roster, or entitlement state is a production incident when wrong, you are hybrid-or-higher. Own the experience. Do not rewrite the schedule engine because HTML got cheap. Unbundling still applies to the CMS skin; it does not license a ground-up rewrite of clinical scheduling.

Ecommerce and marketplace — apply remove/retain

Here the CMS-as-translation-layer and the commerce-as-state-machine are easy to confuse because vendors sold them as one product. WooCommerce and Shopify are not inconvenient page editors. They are transactional systems with order history, payment handling, inventory, refunds, tax, fulfilment and permissions.

Translation layer (replace when it is only a builder): theme choreography, page-builder storefront editing, marketing landing pages that do not need the cart ontology. Those can move to the Post-CMS Stack while the cart still hits the commerce engine.

Commerce engine (retain): catalogue truth, cart, checkout state machine, tax, inventory, refunds, fulfilment handoffs, permissions. Rebuilding all of that because AI can write HTML is a category error.

Reader placement test: if wrong inventory or wrong tax is a business incident, mark ecommerce-tier. Buy or keep the engine that already underwrites that risk. Unbundle only what is translating intention around it.

How to place a site in one meeting

1. List every place the site writes durable state after a visitor acts (orders, bookings, accounts, payments, CRM records).
2. For each write, name the system of record today (WordPress table, Woo, Shopify, HubSpot, email only, practice software).
3. Ask: is this translation of marketing intent, or operational risk we would be foolish to re-underwrite this quarter?
4. Mark the tier by the deepest durable write, not by the prettiest page. A brochure with one “buy now” link into Shopify is not brochure-tier for that flow.
5. Apply remove/retain from the table. Own experience joins. Buy or keep engines that already encode commodity risk.
6. Write the decision in one sentence: “We remove X; we retain Y; we own joins Z.” If you cannot, the placement is not done.

Chapter 7 is the safety half of the same boundary: even brochure sites can become FTP with a chatbot if you unbundle the editor without replacing the invisible guarantees the CMS was providing for free.

The brochure-site argument is correct and still dangerous. Most sites do not need WordPress. Many successors will still be worse than WordPress if they only replace the editor and forget what the product was quietly guaranteeing.

What the CMS was doing when you were not looking

Run this list against any “AI writes the site” proposal. If a line is missing, you do not have a CMS replacement. You have a risk transfer onto whoever holds the keys.

A CMS bundled many of these into a product you rented with annoyance. An agent-native stack must re-home them in ordinary code. That is not optional polish. It is the difference between design-time AI and a stochastic superuser.

FTP with a chatbot

The failure mode has a name worth keeping: FTP with a chatbot. Credentials in the environment. A model that can write anywhere it can reach. No independent gate between proposal and production. Logs that are whatever the model printed. Rollback that is “ask it to put it back.”

That architecture feels fast in week one. It is how you learn, in week six, that speed without a shell is just accelerated incident creation.

The deterministic shell

The mature design is not “give Claude access to the server.” It is:

An open-ended AI worker inside a narrow deterministic shell.

Split the jobs cleanly:

Mapping OPE limits to the checklist

Re-read Chapter 5’s honest limits against the checklist above. Prompt-enforced paths fail permissions and scope. Auto-deploy fails preview and approval and weakens deployment safety. Diff-as-receipt gives version history visibility without making history a gate. Separating checkout from htdocs helps, but without promotion control you still lack a full shell. The specimen is useful precisely because it makes those gaps concrete rather than abstract.

Our Perfect Employee (Chapter 5) is a valuable proof and also a map of the gap: file policy partly prompt-enforced, automatic deploy, diff as receipt rather than gate. The next engineering step is not a smarter model. It is moving those properties from hope into the shell.

Containment beats vibes. You build systems where the AI cannot cause unbounded harm, rather than systems that merely ask it not to. That posture is older than this book; CMS Unbundling simply makes it non-negotiable for websites.

Chapter 8 adds the migration method: the old site is not inspiration. It is the oracle you characterise against — and the chapter that opens the question movement two exists to answer.

“AI can just look at the old site and rebuild it” is true as a starting instinct and false as a method. Looking is not specifying. Specifying is capturing behaviour so the replacement can be wrong in a way you can detect.

Five specifications stacked in one public URL set

1. Visual specification — layout, hierarchy, typography, imagery, responsive behaviour.
2. Content specification — pages, headings, copy, media, calls to action.
3. Behavioural specification — routes, redirects, forms, validation, confirmations, errors.
4. Integration specification — where data goes after submit; email, CRM, booking, payment.
5. Operational clues — the hidden work after a customer touches the site (notifications, queues, manual follow-ups implied by the flow).

What a characterisation pass looks like in practice

You are not “redesigning from screenshots.” You are building a suite that can fail. Capture representative public URLs. For each, record title, meta, canonical, main headings, primary CTA, form fields and validation messages, submit destination (email, CRM endpoint, booking URL), and a screenshot at mobile and desktop widths. Those artefacts become fixtures. The replacement must match or intentionally differ with a written accept-list. Differences without a decision are defects.

A migration agent can crawl and inspect public URLs, titles, metadata, canonicals, structured data, headings, body content, internal links, redirects, forms and field validation, form actions and API calls, email/CRM/booking destinations, screenshots at representative viewports, analytics and consent behaviour. Those become characterisation fixtures. The replacement is compared until every difference is corrected or deliberately accepted as an improvement.

That method is characterisation testing applied to the public web surface: trust the harness, not the model. Observe real behaviour; hypothesise an executable specification; build against it; verify by measurable convergence. The same spirit is Sunk Cost as Spec: configuration and incumbent behaviour are captured requirements, not wasted spend to mourn.

We do not re-teach those frameworks here. We use them. The crawl-and-fixture loop is the migration chapter’s whole job.

HubSpot gets the same decomposition

Do not copy a contact form and declare the CRM obsolete. HubSpot’s fields, lifecycle stages, workflows, attribution, reports, consent handling and integrations are the implicit specification. Extract those first. Observe actual behaviour and workarounds. Then decide what deserves to survive as a commodity service versus a narrow join you own. That is the two-job split applied off the website: translation and convenience screens can go; durable operational state stays until replaced with proof.

The hinge

Movement one is now complete enough to hurt. You can unbundle the translation layer. You can keep deterministic runtime. You can place a site on the transaction-depth spectrum. You can put the AI inside a shell. You can migrate against an oracle.

And then someone asks the question that makes half the industry stay on WordPress:

If we leave the CMS, what happens to the plugin ecosystem?

You do lose install-and-run runtime convenience. That is real. A shared PHP runtime with a plugin directory was an extraordinary distribution channel for solved problems: payments, forms, SEO, memberships, spam.

You do not have to lose the learning encoded in that ecosystem. In fact AI may unlock that learning more fully than the runtime ever did — because an agent can read across many implementations instead of forcing you to adopt one plugin wholesale.

That is not a consolation prize. It is the second half of CMS Unbundling: Ecosystem Decompilation. What follows answers that question with a method, a worked Stripe proof, a convergence discipline, and a prediction for what plugin vendors sell next.

Part III opens on the reframe: WordPress may die as the operating system while surviving as the world’s largest open integration textbook. The job is to mine it without importing its destiny.

Mine it without importing its destiny — that is the half of the argument still open. Unbundling removes the shared WordPress runtime as the place where integrations live. That looks like the downside of leaving. It is only the downside if you thought the asset was the install button.

The asset was the investigation.

What a “simple” payments plugin actually contains

Take a Stripe plugin. It contains far more than the obvious API call to create a payment:

• what configuration users expect;
• how products, prices and currencies are represented;
• when a payment record is created;
• webhook verification;
• payment-success and failure states;
• retries and idempotency;
• abandoned checkouts;
• refunds;
• email confirmations;
• reconciliation with an order or form submission;
• error messages and recovery;
• secrets and permissions;
• API-version changes;
• strange edge cases discovered through years of use.

The plugin may be architecturally ugly and thoroughly WordPress-shaped. It still contains compressed experience. That is Legacy as Tuition operating across an entire public ecosystem: the durable asset is the learning encoded in the implementation, not an obligation to preserve the implementation.

Scale of the corpus

This is not a niche bookshelf. The WordPress.org Plugin Directory advertises over 69,000 free plugins.¹ In 2025 alone, the WordPress Plugins Team reviewed 12,713 plugins — a 40.6% increase on 2024.² Popular listings for Elementor, WooCommerce and contact-form plugins sit in the multi-million active-installation range on the directory’s own labels.¹

Plugin-directory growth continued into 2026 with record submission weeks reported by the Plugins Team.³ Those numbers are not a reason to stay on WordPress. They are a reason to treat the ecosystem as a textbook of solved integration problems — available to any agent that can read source and compare designs.

Why the runtime convenience was never free

Install-and-run felt free because the cost was paid elsewhere: shared-runtime conflicts, plugin update roulette, security patching of code you did not write, and configuration that lived in database tables only one vendor understood. The convenience was real. So was the platform tax. Ecosystem decompilation keeps the learning while refusing the tax as the default price of a contact form or a deposit.

That is why the second movement is not nostalgia for plugins. It is a better extraction method for the only part of the bazaar that still compounds after the CMS translation layer dies.

What the agent is mining for

Not line-by-line clones. Domain distinctions: when a payment is considered final; which identifier is authoritative; which failures are retried; which emails fire once; which configuration is secret versus public; which edge cases only appear after years of chargebacks and abandoned carts. Those distinctions are the tuition. The PHP that expresses them inside WordPress is the packaging.

Ecosystem decompilation, named

This book mints Ecosystem Decompilation as the second component of CMS Unbundling:

Mine many legacy implementations to recover the stable domain pattern, verify it against the current provider surface, and regenerate the smallest locally fitted integration.

That is not “AI casually writes everything.” It is not “fork the most popular plugin.” It is a discipline with a hard rule Chapter 10 exists to defend: never copy one plugin. One implementation imports destiny. Many implementations can reveal invariants.

You lose install-and-run convenience. You keep — and may finally fully use — the accumulated learning. WordPress may die as the operating system while surviving as the world’s largest open integration textbook. Chapter 14 closes on that line; Chapters 10–13 make it operational.

The first reflex after leaving WordPress is to steal a plugin. Download the Stripe zip. Paste the “important parts” into your new stack. Ship by Friday. It feels like thrift. It is usually the most expensive shortcut available.

That reflex imports more than code. It imports a compiled North Star — thousands of design decisions aimed at someone else’s mission, baked into schemas, boundaries, names and tests.

Never-copy-one is not purism. It is the rule that keeps movement two empirical. Without it, “ecosystem decompilation” collapses into forking with better marketing language.

What one WordPress Stripe plugin smuggles in

Even a “simple payments” plugin is organised around WordPress as the operating system of the integration:

• WordPress hooks and filter assumptions — behaviour that only runs because add_action fired in the shared runtime;
• WordPress database tables and the options API — configuration as rows and autoloaded options, not as your schema;
• WooCommerce order models even when you only needed a deposit — cart, line items, order statuses, admin list tables;
• wp-admin configuration screens — the human product surface you were trying to leave;
• cron assumptions — scheduled tasks that expect WP-Cron or a host that pings it;
• PHP compatibility and plugin-header baggage;
• backwards compatibility with years of releases — dead branches that still shape the happy path;
• commercial upsell architecture — free core, paid tiers, nags, telemetry, license checks.

Even excellent code can be organised around the wrong mission. The technical debt is often not poor quality. It is good code aimed at a different product. That is architecture debt: systemic misalignment that does not show up as a broken unit test.

Copy the plugin and you inherit that mission. Your deposit flow becomes a half-ported store. Your agent spends tokens appeasing hooks that only existed because WordPress was the bus. You did not escape the CMS. You smuggled its ontology into the successor.

Parts and priors, not foundations

The useful question is no longer: which project should we fork? It is: what did each project learn that we should carry into our design?

Treat public plugins as a parts and priors library. Extract connectors, event schemas, retry strategies, failure modes, fixture data, terminology, and the things they tried and later removed. Borrow individual libraries where the contract is genuinely commodity — a signature verifier with a clear input and output, not a half-app. Treat the project as a design specimen, not as your foundation.

Copy discoveries, not destiny.

Discoveries look like: “fulfilment must not trust the browser return URL alone.” Destiny looks like: “orders live in wp_posts with this meta shape and this admin list table.” The first survives any stack. The second is WordPress wearing a payments costume.

Read a plugin at five levels

Before you decide what to keep from any specimen, walk it the way you would walk a mature repository. Skimming the readme is not a walk.

Work a Stripe plugin quickly at those levels and the fork decision often answers itself. Code level may offer a useful webhook signature helper. Architecture is organised around Woo hooks. Ontology is Order, Product, Coupon. Workflow is cart → checkout → order statuses. North Star is “be a commercial WordPress payments product.” Your North Star might be “take a $250 deposit and notify staff.” Those are not the same system. Lift the discoveries from levels one through four that survive contact with your mission. Generate the organism.

One specimen still misleads — even when you read it well. A careful walk of a single plugin can make a local choice look universal because you have no contrast. Chapter 11 adds the empirical test: convergence across independent implementations. That is where never-copy-one becomes operational rather than merely cautionary.

Never-copy-one (Chapter 10) stops you importing destiny. It does not yet tell you which discoveries are load-bearing. Popularity is not that test. A single elegant codebase is not that test. Agreement across implementations that did not share a design committee is closer to a test — still only a prior until you verify against the live provider.

The method loop

Many independent implementations
        ↓
Common entities, states and failure cases
        ↓
Candidate integration invariant
        ↓
Verify against current provider contract
        ↓
Encode as automated test
        ↓
Generate locally fitted adapter
        ↓
Sandbox + fixture verification

That loop is adjacent to generative design patterns: the reusable object moves upstream from complete code to the promptable invariant, domain distinctions, schemas and evaluation cases. We do not restate that framework. We use its posture: mine the family, do not worship one member.

Worked method demonstration: Stripe payment plugins

What follows is a method demonstration, not a survey result with fabricated counts. The claim is not “exactly eight of eight plugins do X in a study we invented.” The claim is: if you open a named, checkable set of independent Stripe integrations and score the same concerns, the method forces a discrimination between invariant and local choice — and that discrimination is what ecosystem decompilation runs on.

A named, checkable set

For a payment-deposit shape, open a set like the following (public WordPress.org / vendor source where available) and treat each as a specimen, not an authority:

1. WooCommerce Stripe Payment Gateway (Automattic / WooCommerce ecosystem)
2. Payment Plugins for Stripe WooCommerce (independent WooCommerce connector lineage)
3. WP Simple Pay (Stripe-focused WordPress payments, not full Woo ontology)
4. Stripe Tax / Stripe-adjacent official extension code samples in provider docs
5. A Magento or Shopware Stripe module (non-WordPress control)
6. A Laravel Cashier or equivalent framework integration (non-CMS control)
7. A Next.js / serverless Checkout sample from Stripe’s own examples
8. Your incumbent site’s actual payment behaviour (characterisation, not a plugin)

Eight rows is a convenient working set because it forces cross-stack comparison. Substitute any checkable independents you can actually read. The method fails if you only open forks of the same plugin.

The discrimination table

Read the table row by row. Where independent implementations converge on a concern and the current Stripe contract agrees, you have a candidate invariant to encode as a test. Where they diverge (admin UI, full order models, branding of settings pages), you have local choice — discard unless your business requires it.

Three discrimination calls in prose

The table is a scoreboard. The method is the judgement. Walk three rows the way an agent (or a careful human) should, using the named set as contrast — still without inventing “N of 8” survey counts.

Call 1 — Signed webhooks: invariant candidate

Open the WooCommerce Stripe gateway, an independent Woo Stripe connector, WP Simple Pay, and a non-WordPress sample (Laravel Cashier or Stripe’s own Checkout sample). Ask the same question at the workflow level: when an event arrives claiming payment succeeded, does the code verify the signature (or equivalent authenticity check) before mutating business state?

What you typically find across serious, independent lineages is not identical code. You find the same distinction: unauthenticated event bodies are not trusted. A WordPress plugin may use Stripe’s PHP helper inside a REST route; a framework sample may verify in middleware; an official sample may show constructEvent with the webhook secret. The implementations diverge. The concern converges.

Discrimination: mark invariant candidate. Then verify against Stripe’s current docs and your test-mode endpoint: a tampered payload must fail closed. Only after that encode a test. Popularity never entered the argument — independent recurrence plus live contract did.

Call 2 — Admin settings UI: local choice

Now score “how configuration is presented to humans.” One plugin ships a dense WooCommerce settings tab with dozens of toggles. Another uses a slim custom post type screen. A third leans on wp-admin notices and a setup wizard. A framework sample has no admin UI at all — environment variables and code.

There is no stable shape. The provider does not require a particular settings screen. The divergence is the signal: admin UX is optimised for WordPress operators and vendor packaging, not for the physics of Checkout Sessions.

Discrimination: mark local choice. Discard with the CMS admin when you leave. Your successor might use a conversation (“use the test key in staging”), a secrets vault, or a tiny config file. Copying any one plugin’s settings IA would re-import job-one translation theatre as if it were payment correctness.

Call 3 — Full Woo order ontology for a deposit: local / platform choice

Compare a Woo-centric Stripe plugin with WP Simple Pay and a raw Checkout sample against the intent “take a $250 deposit.” The Woo lineage elevates Order, Product, line items, order statuses and admin order notes. Simple Pay and bare Checkout can complete a payment with a session and metadata. Stripe’s API is fine with a single-purpose Checkout Session; it does not require a catalogue.

Where independent non-store implementations free themselves from Order-as-centre, and the provider contract does not demand it, the full commerce ontology is not an integration invariant. It is the North Star of “be a store plugin.”

Discrimination: for a deposit, mark local / platform choice unless you are actually operating a multi-product store. Carry the discoveries (pending state, webhook authority, idempotency). Leave the order graph behind. Chapter 12’s seven-field schema is what that judgement looks like when compiled into a local adapter.

Evidence, never authority

A public plugin repository may be obsolete, insecure, badly implemented, constrained by old WordPress versions, designed around WooCommerce assumptions, incompletely licensed for copying, carrying backwards-compatibility cruft, using a deprecated provider API, or solving commercial plugin-vendor needs rather than customer needs.

So the agent must never reason:

"A popular plugin does it this way, therefore this is correct."

It must reason:

"Several historical implementations suggest this distinction
or failure case. I will verify it against the current provider
contract and encode it as a test."

Chapter 12 runs that loop end to end for a $250 deposit — schema, endpoints, verification — without importing a commerce ontology.

Stripe is the ideal decompilation case because the provider already offers complementary agent-operable surfaces: developer-friendly APIs and SDKs, clear event and object models, test mode and test cards, webhooks, strong documentation, MCP/tool access for agents, and a huge population of existing integrations. That combination lets an agent move through a tight loop without pretending a CMS is the integration bus.

Step 1 — Intent

Take a $250 deposit for this booking.

Notice what the sentence does not say: multi-product catalogue, coupons, inventory, customer accounts, subscription plans. A deposit is a single-purpose transaction. The adapter should be the same width as the sentence.

Step 2 — Current provider truth

Before reading any plugin, read Stripe. Official MCP documentation describes a hosted Model Context Protocol server at https://mcp.stripe.com that agents can use to interact with the Stripe API and search documentation and support knowledge. Tools include API search and details, generic read/write across large parts of the API surface, account info, refunds, documentation search and an implementation planner; administrators enable MCP access separately for sandbox and live mode.⁴

MCP does not replace webhooks, test mode or signed events. Stripe also publishes a broader agents hub for building with agent-first developer tools.⁵ It improves the agent’s ability to discover and operate the current contract. The hierarchy in Chapter 13 starts here: use the provider’s agent-operable surface first.

Step 3 — Mine priors (without copying destiny)

Apply Chapter 11’s discrimination. From independent payment integrations you expect candidate invariants:

• separate provider payment/session id from local quote id;
• verify signed webhooks;
• treat webhook receipt as authoritative over browser return;
• idempotent handlers;
• pending state between checkout creation and confirmation;
• persist the event before fulfilment side effects.

Discard local choices: wp-admin settings screens, full Woo order graphs, plugin upsell flows, theme-specific success pages as the settlement mechanism.

Step 4 — Local truth

Recover what this site actually needs. A client quote-to-payment flow is a useful primitive specimen: retrieve the quote, create a Checkout session, complete through webhook listeners. Booking context may add customer email, deposit amount, currency and a reference that ties payment to the appointment or quote. Incumbent behaviour (if any) becomes characterisation fixtures: amounts, success and cancel URLs, staff notifications, CRM updates.

Step 5 — Seven-field schema, justified field by field

The generated integration need not inherit a commerce ontology. For the deposit intent, the durable local record can stay seven fields wide. Each field earns its place; anything not required by the intent or the invariants is refused.

No product catalogue. No cart. No coupons. No inventory engine. No WooCommerce order model unless the business actually needs them. If a field only exists because a plugin had an admin column, it fails the intent test and stays out.

Step 6 — Two endpoints, including unhappy paths

Checkout create

POST /api/deposits
  body: { quote_id, customer_email }
  server:
    load quote → assert amount $250 (or quote amount)
    insert row payment_status=pending
    create Stripe Checkout Session (test mode keys in non-prod)
    store checkout_session_id
    return session URL
  client:
    redirect browser to Stripe Checkout

Unhappy paths the create endpoint must own:

• Unknown quote_id — 404/422; no Stripe session; no pending row or a failed attempt log only.
• Amount mismatch — if the client tries to pass amount, ignore it; server loads amount from quote. Fail closed if quote amount is missing or zero.
• Stripe API error — leave status failed or delete pending; return a safe error; do not redirect to a half-created session.
• Repeat create for same quote — decide explicitly: expire prior session and create new, or return existing open session; never silent double-charge paths without a product rule.

Webhook complete

POST /api/stripe/webhook
  server:
    verify signature (reject if invalid)
    parse event; if duplicate event id → 200 and stop (idempotent)
    on checkout.session.completed (or equivalent):
      record event
      set payment_status=paid, paid_at=now
      then fulfilment: notify office, update booking, etc.
  browser success URL:
    UX only — "we received your payment; confirmation follows"
    never the sole authority for fulfilment

Unhappy paths the webhook must own:

• Invalid signature — 400; no state change; no fulfilment. This is the forged-event path.
• Duplicate event id — 200 with no second email, no second unlock. Stripe retries; your handler must be idempotent.
• Session completed but unknown checkout_session_id — log and alert; do not invent a quote. Manual reconciliation beats silent mis-fulfilment.
• Expired / abandoned session events — move pending → expired; never paid_at.
• Browser success without webhook — show “processing” UX; fulfilment waits for signed event. That single rule is where most DIY integrations lie to themselves.

Step 7 — Sandbox run vs replayed fixtures

The plugin corpus nominated cases. Two different verification modes prove different things. Using only one leaves a hole the other mode covers.

What the live sandbox (test mode) run proves

Drive real Checkout in Stripe test mode with test cards: success, decline, authentication failure. This proves the integration with the current provider surface — API versions, redirect URLs, session create parameters, Dashboard-visible objects, and that your keys and webhook endpoint registration actually work end to end. It catches “our code assumes a field Stripe renamed” and “the success URL is wrong in this environment.”

Sandbox is weaker on rare paths you cannot cheaply force on demand (exact retry timing, historical payload shapes, offline webhook storms). It is also slower as a regression suite if every test needs a browser.

What replayed signed fixtures prove

Store signed (or signature-verifiable) webhook payloads for completed, expired and duplicate delivery. Replay them in CI against the handler. This proves your state machine and side-effect discipline: idempotency, record-before-fulfil, reject-on-bad-signature, no fulfil on browser-only success (paired with a unit test of the success route). Fixtures are fast, deterministic and good at unhappy paths.

Fixtures are weaker at proving the live provider still accepts your session-create shape tomorrow. A frozen fixture suite can stay green while Checkout create is already broken in production.

Both, deliberately

1. Test mode Checkout — success, decline, auth failure (provider contract alive).
2. Replayed webhook fixtures — completed, expired, duplicate (handler correctness).
3. Idempotency — same event twice; fulfilment once.
4. Browser-return-without-webhook — success URL alone; no fulfilment.
5. Signature failure — tampered payload rejected.
6. Amount mismatch — session amount must match quote; fail closed at create time.

Intent: "Take a $250 deposit for this booking."
Current truth: Stripe API, SDK, MCP, test mode
Prior experience: multi-impl convergence (Ch 11)
Local truth: quote/booking model + incumbent behaviour
Implementation: one checkout endpoint + one webhook endpoint
Verification: sandbox (provider alive) + fixtures (handler correct)

Characterisation tests — not confidence in the AI — are the arbiter. If a step wants a metric the sources do not have (minutes-to-integrate, conversion lift), write the shape instead of inventing the number.

Chapter 13 generalises the construction order and shows what a vendor ships when the product is a pattern package rather than a WordPress zip.

Chapter 12 was one transaction. This chapter is the search order and the market shape that make the method repeatable.

Integration construction hierarchy

Use this order. Stopping early is a feature when the provider surface is already excellent.

1. Use the provider directly

Ask whether the provider already exposes an agent-operable surface: MCP, official SDK, OpenAPI specification, CLI, sandbox, webhook tools, maintained examples. For Stripe, the answer is largely yes. For a random SaaS with only a human portal, the answer is no — and that becomes an addressability problem for the vendor, not a reason to install a WordPress middleman forever.

Stop here when: docs + sandbox + SDK/MCP cover the transaction shape and you can write tests without archaeology.

2. Mine existing implementations

Read plugins and connectors to discover standard flow, hidden edge cases, expected configuration, lifecycle and error states, migration concerns, provider quirks. Apply never-copy-one and convergence (Chapters 10–11).

Stop here when: candidate invariants are listed and each has a verification path against the live contract.

3. Recover the incumbent behaviour

Inspect what the current website actually does: payment amount and timing, return and cancellation behaviour, emails, CRM/order updates, refunds, staff alerts, reconciliation. Characterise it (Chapter 8).

Stop here when: fixtures exist for the paths customers actually hit.

4. Generate the narrow local adapter

Build only the business-specific join between the site and the commodity provider. Seven fields beat a commerce ontology for a deposit. Own the join; buy the capability.

5. Generate tests before production

The plugin corpus nominates cases; the provider sandbox and incumbent behaviour turn them into executable acceptance tests. Characterisation tests, rather than confidence in the AI, become the arbiter.

From plugin bazaar to pattern bazaar

Today a plugin vendor sells:

Install our code into WordPress and configure it through our screens.

The AI-native successor sells:

Give your agent our maintained integration package: domain model, current API interpretation, pattern card, security rules, fixtures, edge cases, test suite and update feed.

AI then generates the customer-specific implementation. The vendor does not necessarily disappear. The commercial asset migrates from one executable plugin to maintained integration knowledge and proof.

Specimen package outline: Stripe integration for agents

What a serious vendor might ship instead of a zip for wp-admin:

That package fits the inverted reuse hierarchy: North Star → domain distinctions → schemas and eval cases → bounded libraries → complete application code. The complete plugin falls in relative value. The accumulated integration discrimination rises.

How the hierarchy prevents two common failures

Eager generation. An agent that jumps to step 4 produces a clever adapter against last year’s mental model of Stripe. Starting at step 1 forces contact with the live contract and MCP/docs before any plugin nostalgia loads.

Corpus worship. An agent that lives in step 2 forever will re-implement WooCommerce. The hierarchy ranks mining as prior, not destination. Step 3 pulls the agent back to this business. Step 5 refuses production without tests the corpus only nominated.

Together with never-copy-one and convergence, the hierarchy is how ecosystem decompilation stays a method rather than a slogan. Pattern packages (above) are what the market can sell so step 2 becomes less archaeology and more subscribed discrimination — still verified at step 1 and step 5 every time the contract moves.

Chapter 14 closes the value migration and hands the reader the portable operating model.

The early framing of leaving WordPress treated the plugin ecosystem as the main downside. That framing was incomplete. You lose install-and-run convenience. You do not lose accumulated learning. AI can read across the ecosystem instead of forcing wholesale adoption of one plugin’s destiny.

WordPress may die as the operating system while surviving as the world’s largest open integration textbook.

Sharper still: the plugin ecosystem stops being a shelf of components and becomes a corpus of integration experience. Plugin vendors’ durable asset migrates from an executable zip to maintained knowledge, fixtures, threat models and update feeds. That is value migration for a whole category, not a feature request for a page builder.

One disambiguation

Semantic decompilation shares a word with ecosystem decompilation, not a mechanism. Semantic decompilation, in adjacent work, reverse-engineers idea systems and prose into structured meaning. Ecosystem decompilation mines software implementations of integrations for verified invariants. Do not collapse them. This book owns only the second.

The same decompilation loop generalises to connector ecosystems beyond the web — AppExchange, Zapier-like galleries, ERP adapters, browser extensions — and this book proves it where the evidence actually is: the plugin corpus and the web stack under your feet.

What unbundling leaves standing

After both movements, three things should be clear enough to act on without re-reading the whole book.

First, the CMS was never one product. The translation layer and the operational plane had different fates under AI. Driving WordPress with an agent tries to preserve the fusion. Unbundling accepts the split.

Second, plugins were never only install buttons. They were compressed investigations. Losing the shared runtime is not the same as losing the learning — if you decompile with never-copy-one, convergence, and provider verification.

Third, the successor is not vibes and production credentials. It is conversation into Git-addressable source inside a deterministic shell, commodity services for durable risk, and tests as the arbiter of generated joins.

The operating model

After this book you should be able to run the following without a consultant in the room.

1. Two-job decomposition

On any CMS-shaped platform (WordPress, Squarespace, HubSpot site tools, page builders), ask: what is human translation between intent and artefact? What is durable operational state and commodity risk? Remove or replace the first with conversation-to-source. Unbundle the second into shell + services + joins.

2. Transaction-depth placement

Brochure → lead-gen → booking/membership → ecommerce/marketplace. Apply remove/retain from Chapter 6. Do not rebuild tax and inventory for sport. Do not keep a full CMS for a three-page brochure out of habit.

3. Post-CMS Stack with deterministic shell

Conversation and visual AI at the top. Git-native source. Ordinary code for auth, tests, diff, approval, deploy, logs, rollback. Static site plus small endpoints. Commodity APIs underneath. Invisible-guarantees checklist complete before production credentials exist.

4. Ecosystem decompilation for integrations

Provider surface first. Mine many implementations. Converge to invariants. Never copy one plugin. Verify against the current contract. Encode tests. Generate the narrow adapter. Prefer pattern packages over runtime plugins when vendors offer them.

What we minted

CMS Unbundling is the framework: two-job decomposition, compiler-between-compilers, design-time AI with deterministic runtime, transaction-depth boundary, invisible-guarantees shell, incumbent as oracle, and the hinge into ecosystem learning.

Ecosystem Decompilation is the concept inside it that answers the plugin question: mine many implementations, verify against the live provider, regenerate the smallest fit. Corpus is evidence, never authority. Never-copy-one is the discipline that keeps the second movement respectable.

Closing

Putting AI into WordPress keeps failing because it preserves a compiler humans needed and machines do not. The replacement is not a smarter admin theme. It is a site the owner’s AI can operate: conversation instead of the editor, Git and tests instead of an opaque content representation, commodity APIs instead of a plugin bazaar — and the plugin bazaar’s learning retained as a textbook you decompile rather than a runtime you rent.

AI does not make the CMS smarter; it unbundles it. The future website is not built for a business owner to administer. It is built for the business owner’s AI to operate.