Stop Treating WordPress Like a CMS and Start Building It Like Software

Six months ago, I convinced a client that WordPress could handle their marketplace platform. They needed user roles, custom listings, filtering, premium tiers, and payment processing. I remember sitting in that kickoff meeting thinking, "It's just WordPress, how hard could this be?" By week three, I was knee-deep in custom post types, custom taxonomies, and a database schema that looked like spaghetti code.

That's when it hit me: I wasn't building a website anymore. I was building a platform. And I was trying to do it with the mindset of someone bolting plugins together.

Reading through Perceval's approach to planning a complex WordPress project made me realize I wasn't alone in this struggle—but more importantly, it validated something I've come to believe: the difference between a successful large WordPress project and a nightmare is exactly what separates junior and senior development thinking.

The Architecture First Mentality

Perceval nails something that took me painful months to learn: planning beats coding. Every time.

I used to dive into WordPress projects by installing plugins and hacking away at functions.php. It felt productive. Lines of code were flowing. But about halfway through, I'd hit a wall where adding a new feature meant touching ten different places. Database queries multiplied. Performance tanked. The codebase became unmaintainable.

What changed for me was shifting to architectural thinking before opening the IDE. For that marketplace project, I spent two weeks—just planning. Database schemas. User permission matrices. Hook dependency maps. Plugin load order. Which custom post types vs. custom tables. Only then did I write code.

This upfront work felt slow initially, but it saved me weeks down the line because I wasn't refactoring core functionality mid-project.

When WordPress Is the Right Tool—and When It Isn't

Here's my honest take: WordPress can absolutely handle complex platforms. But there's a threshold where you need to stop thinking like a WordPress developer and start thinking like a software architect who happens to be using WordPress.

For authentication, custom dashboards, advanced filtering, and API integrations, WordPress forces you to think differently than standard theme-plugin development. You're wrestling with a system that was fundamentally designed for blogs, extended to handle e-commerce, but never really designed for multi-tenant platform architecture.

I've started asking hard questions upfront: Do we actually need WordPress here, or are we using it because it's familiar? Could a headless approach (Next.js + a REST API) work better? Would a purpose-built framework give us cleaner code?

Sometimes the answer is still yes to WordPress. Sometimes it isn't.

Breaking Work Into Milestones Actually Matters

Perceval's breakdown—core site, then auth, then listings, then search, then premium features—mirrors how I've started planning my own projects. The temptation is always to build the "full vision" in parallel. Ship it all at once.

That's a recipe for shipping nothing.

By shipping small, working pieces, you get feedback loops. You can actually test with real users before investing six months in features that don't matter. You catch architectural problems early when they're cheaper to fix.

My Actual Approach Now

For that marketplace platform, here's what I actually did differently:

I used custom tables (not custom post types) for listing data. WordPress posts were too heavy for what we needed. I built a custom authentication system that integrated with WordPress but wasn't dependent on it. I created a plugin-agnostic hook system. And I wrote extensive integration tests before touching the UI.

Was it more work upfront? Yes. Did it save me from disaster? Absolutely.

// Instead of relying on post meta, I query custom tables
class ListingRepository {
    public function getListingsByFilter($filters) {
        $query = "SELECT * FROM listings WHERE status = 'published'";
        
        if (!empty($filters['price_min'])) {
            $query .= $wpdb->prepare(" AND price >= %d", $filters['price_min']);
        }
        
        return $wpdb->get_results($query);
    }
}

This approach is faster, cleaner, and doesn't fight WordPress's data model.

The Real Question

Reading Perceval's perspective made me wonder: are we as WordPress developers doing ourselves a disservice by not acknowledging when WordPress is a constraint rather than a solution?

I'm not saying abandon WordPress. I'm saying approach it with humility. Treat complex WordPress projects like real software projects, because they are.

So here's my question for you: if you're building something genuinely complex in WordPress right now, what's your architecture story? Are you planning first or coding first? What's breaking?

Source: This post was inspired by "Building a Complex WordPress Platform from Scratch" by Dev.to. Read the original article