Building a SaaS on WordPress: Yes, Really

Every time I tell another developer that WordPress is a legitimate application platform, I can see the exact moment their brain checks out. Their eyes glaze over. They’re already composing their “just use Laravel” response. And I get it - if your only experience with WordPress is installing themes and fighting with page builders, the idea of building serious software on it sounds insane.

But I didn’t learn WordPress the normal way. I learned it by reverse-engineering the core codebase, reading source code line by line until I understood how every piece connected. I came in the back door, up the building, across the street, and dug a tunnel. And what I found inside was an application framework that most people never see because they stop at the blog layer.

The Hook System Changed How I Think About Software

WordPress’s action and filter hook system is, in my opinion, one of the most underappreciated architectural patterns in software development. It’s an event-driven plugin architecture that lets you modify virtually any behavior without touching core code.

// This isn't just WordPress. This is a philosophy.
add_filter('the_content', function($content) {
    // You can intercept and transform anything
    // without modifying the source
    return modify_content($content);
});

That pattern - the idea that software should have hooks everywhere, that any behavior should be interceptable and modifiable by outside code - shaped how I architect all software now. Not just WordPress projects. Everything. When I’m building React components at my day job at StudioRx, I’m thinking about extensibility points. When I’m structuring an Electron app, I’m thinking about where the hooks should go.

WordPress taught me that, and I don’t think it gets enough credit for it.

What WordPress Actually Gives You (That You’d Build From Scratch Otherwise)

When people dismiss WordPress as “just a CMS,” they’re ignoring an enormous amount of battle-tested infrastructure:

• User management: Registration, authentication, roles, capabilities, password security, session management. All production-ready. All tested by 43% of the web.
• REST API: Full CRUD endpoints for every content type, with authentication, permissions, and extensibility built in.
• Custom post types and taxonomies: A flexible data modeling system that handles 80% of application data structures.
• The media system: File uploads, image processing, responsive image generation. Boring stuff that takes weeks to build right.
• The admin interface: A complete back-office UI for managing data, users, and settings.

I’m not going to pretend I’ve built three SaaS products on WordPress, because I haven’t. But I’ve spent 16 years building applications on it for clients, and I’ve seen firsthand how much development time you save by starting with this infrastructure instead of rebuilding it from scratch in whatever framework is trendy this month.

The Glaze Story (Or: The SaaS I Almost Built)

Years ago, I was working on a project called Glaze. It was a product idea that would have been WordPress-based - leveraging custom post types, the REST API, and the entire hook ecosystem to build something that felt like a modern app but ran on WordPress’s backend.

I was deep into Backbone.js at the time for the frontend, struggling with state management. Then I went to a tiny WordCamp in Saratoga, NY, and a French Automattic engineer named Bo was giving a Backbone talk but couldn’t stop talking about React. That moment redirected my frontend approach, but the backend architecture - the WordPress part - was solid. Custom post types as application entities. The hook system for business logic. Custom REST endpoints for the API layer.

Glaze didn’t ship as a product, but the architecture I designed for it has influenced every WordPress application I’ve built since.

WordPress as Backend, Modern Frontend

The headless WordPress approach - using WordPress as a backend API with a separate frontend - is where things get genuinely interesting for application development:

// Custom REST endpoint for application data
add_action('rest_api_init', function() {
    register_rest_route('myapp/v1', '/dashboard', [
        'methods'  => 'GET',
        'callback' => 'get_dashboard_data',
        'permission_callback' => function() {
            return current_user_can('access_dashboard');
        }
    ]);
});

You get WordPress’s authentication, permissions, and data layer without being locked into WordPress’s frontend. Build your UI in React, Vue (my preference), or whatever framework your team uses. WordPress handles the boring-but-critical backend stuff it’s been doing reliably for two decades.

The Hosting Business Proof of Concept

I host a deliberately small roster of client sites on a Linode server I’ve managed myself for the better part of 16 years. cPanel throughout, LiteSpeed only recently. The whole stack is mine. Six clients pay full price - $20 a month - two nonprofits pay half, and a few more ride along free on multi-site setups. It’s small on purpose, and I’d rather keep it sustainable than chase scale.

That’s only possible because of two things: WordPress’s architecture makes maintenance predictable and scriptable, and AI tools (specifically Claude Code) let me handle issues across the whole roster without it eating my life.

This isn’t a SaaS, but it’s a real business running on WordPress that works because the platform is reliable enough to bet your income on. I’ve been betting my income on it for 16 years through my company, 211j. I’m not about to stop.

When WordPress Is the Wrong Choice

I’m a WordPress believer, not a WordPress zealot. There are plenty of cases where it’s the wrong tool:

• Real-time applications: Chat, collaborative editing, live dashboards - you want WebSockets and a Node backend, not WordPress.
• Data-heavy computation: Analytics engines, machine learning pipelines, anything that needs to crunch large datasets.
• High-frequency API services: If you’re handling thousands of requests per second with sub-10ms latency requirements, PHP isn’t your friend.

But for content-driven applications, membership platforms, client portals, booking systems, directory sites, and about a hundred other common web application patterns? WordPress gives you a massive head start.

The Real Point

The developers who dismiss WordPress without understanding its architecture are making the same mistake as the developers who dismiss any technology without trying it. And that’s a mistake I’m constitutionally incapable of making - my FOMO won’t allow it.

WordPress isn’t just a blogging platform. It’s an application framework with 20 years of battle-testing, an event-driven architecture that most developers don’t appreciate until they build with it, and an ecosystem that makes rapid development genuinely possible.

You don’t have to use it. But if you dismiss it without understanding what’s under the hood, you’re leaving a serious tool on the table. And in this industry, we need every tool we can get.