The consensus story about WordPress is that it is a content management system. This is true in the same way that the consensus story about a car is that it is a device for holding four seats. Technically accurate, and also missing the point of what the thing actually does in most of the situations you find it in.
In a business with any operational complexity, the WordPress installation stopped being primarily about content years ago. It is the layer where the customer places an order, and the order goes to a payment processor. It is the layer where the payment gets confirmed, and the order gets forwarded to the fulfillment platform. It is the layer where the fulfillment platform reports a shipment, and the customer record in the CRM gets updated. It is the layer where the inventory count comes back from seven physical locations and gets reconciled against the storefront’s product availability. Content is happening on the site, sure. So is a lot of other work, and the other work is what actually makes the business run.
Once you see it that way, the platform stops looking like a website builder and starts looking like what it actually is, which is an integration hub with a content management system attached to it.
Why the reframe matters
The reframe is not academic. It changes which questions you ask on day one of a build, and which decisions you make about how the system is structured.
If you are building a CMS, the important questions are about editorial workflow, content architecture, and how non-technical staff will manage the site. Those questions still matter. But they are not the questions that determine whether the system works six months in. The questions that determine that are integration-shaped: how does data move between this platform and the operational systems it connects to, how does the platform respond when one of those systems is slow or offline, and how much of the business’s actual truth lives in the platform versus somewhere else.
I have inherited WordPress installations that were built as if content were the point. The theme was beautiful. The editorial workflow was smooth. The integrations were held together with a plugin someone had installed three years ago, configured by a developer who was no longer reachable, syncing data on a schedule that nobody had documented, into fields that had been renamed twice since the sync was set up. When the CRM stopped receiving new leads, it took a week of forensic work to figure out where the break had happened, because the integration layer had been treated as plumbing rather than as the central nervous system of the operation.
That is the cost of treating WordPress as a CMS in a context where it is really an integration hub. The important part of the system gets treated as an afterthought, and it fails accordingly.
What the work actually is
The work of maintaining an integration-hub WordPress installation looks a lot more like the work of maintaining an internal tools platform than the work of maintaining a website. The daily reality involves API contracts with three or four external systems, each with its own authentication scheme, its own idea of what a customer record looks like, and its own tolerance for downtime. It involves webhook handlers that receive updates from those systems and update the WordPress database in response. It involves scheduled reconciliation jobs that check for drift between what WordPress thinks is true and what the CRM thinks is true, and either automatically correct the drift or flag it for a human to look at.
The plugins that come with WordPress out of the box do a portion of this, badly. They will accept an order and send it to a fulfillment platform, but if the fulfillment platform is slow to respond, the order will sit in a limbo state that nobody notices until a customer calls asking where their package is. They will sync contact records to a CRM, but if the CRM rejects a record for a schema mismatch, the sync will fail silently and the record will never make it. Every one of these failure modes is fixable, and every one of them requires custom code, and none of them are visible until they cause a specific problem in production.
The engineer building on WordPress for a company with real operational stakes spends most of their time in this layer. The theme work is a small fraction of it. The integration work is the bulk of it, and it looks technically identical to the work of maintaining an internal tooling platform: API design, retry logic, error handling, logging, credential rotation, schema validation, data reconciliation. The only reason it does not get called that is that it happens to be running inside a system that also, incidentally, publishes blog posts.
The translation to other platforms
The exact same reframe applies to HubSpot and Airtable, which is the reason the reframe matters if you are looking at either of those platforms from a WordPress background.
HubSpot gets marketed as a marketing automation platform, and in a company with any operational complexity it quietly becomes something else: the customer data layer connecting sales tools, marketing tools, finance tools, and whatever operational systems sit downstream of all three. A custom object in HubSpot is an entity definition in a shared data model in the same way a custom post type is in WordPress. A property definition is a schema decision in the same way an ACF field group is. The vocabulary is different. The decision being made is not.
Airtable takes a different route to the same place. It gets used as a database, or a spreadsheet, or a lightweight project tracker, and underneath any of those uses it is a shared data layer that other systems read from and write to via API, with a human-usable interface sitting on top of the wiring. Where HubSpot’s version of this decision is a custom object, Airtable’s is a base design choice: which table owns which entity, and what an automation is allowed to write back into it once it runs.
What does not transfer for free is the vendor-specific part: HubSpot’s workflow engine has its own quirks about enrollment triggers and re-enrollment, and Airtable’s automations hit rate limits and script-run timeouts that have nothing to do with WordPress at all. I would not walk into either platform claiming I already know its API’s edge cases, because I don’t yet. What transfers is the upstream decision — what are the entities, how do they relate, what breaks when two systems disagree about the answer — and that decision is the harder half of the job in any of the three platforms.
What this changes about how I position the work
I stopped calling myself a WordPress developer at client meetings a while ago, not because the WordPress work went away, but because the label was pointing at the wrong thing. What I actually do, on any given engagement, is design and maintain the integration layer that connects a business’s operational systems together. The fact that the layer is running on WordPress, or WooCommerce, or a headless combination of both, is an implementation detail. The underlying work is the same work an in-house systems engineer does on a HubSpot instance or an Airtable base, and the discipline required to do it well is the same discipline.
The clients who came to me thinking they needed a WordPress developer usually turned out to need this instead. They knew their systems did not talk to each other well, they knew data was getting lost between platforms, and they knew someone needed to own the layer where all the connections lived. WordPress happened to be sitting in the middle of their stack, so they hired someone who could work on WordPress. What they actually needed was someone who could think about the whole stack. The best of the engagements were the ones where the client eventually stopped thinking of me as their WordPress person and started thinking of me as the person who owned how the systems talked to each other.
That is the useful way to think about the work, and it is also the practical test I would apply to any new platform before taking a role built around it: find where the systems are supposed to hand off to each other, and go look at what actually happens at the handoff. That is where the job lives, regardless of what the login screen says the product is.