Dhruv Koladiya
For years, “should we use WordPress?” wasn't really a question we asked — it was the answer, by default, unless someone gave us a specific reason not to. That's changed. Not because WordPress got worse, but because the range of projects landing on our desk got wider, and a one-size answer stopped fitting most of them.
The tipping point was a project for a client running a fairly complex product catalog with custom pricing rules tied to customer accounts. We could have forced it into WordPress with a stack of plugins, and for the first few months it probably would have worked fine. The problem shows up later: plugin updates that quietly break each other, page load times that creep up as the plugin count grows, and a codebase that's really three different developers' plugin choices stitched together rather than one coherent system.
What we actually check before recommending anything
We ask three questions before picking a platform, and none of them are “what do we know best.” First: how much of the requirement is genuinely content management — blog posts, landing pages, a marketing team that wants to edit copy without a developer — versus how much is application logic, like custom workflows, calculations, or integrations with other systems. The more it leans toward the second, the weaker the case for a CMS-first platform gets.
Second: who's maintaining this in eighteen months? A client with an in-house marketing team who wants to add pages themselves is a very different answer than a client whose site barely changes once launched. WordPress earns its keep when non-technical people need to touch the site regularly. If nobody's touching it after launch, the ongoing plugin-update maintenance burden stops paying for itself.
Third, and the one we underweighted for years: what does the hosting and security story look like at the client's actual budget? A poorly maintained WordPress install is one of the more common ways small business sites get compromised, and “we'll just keep it updated” is a commitment that quietly falls off after the invoice is paid, on both sides.
Where it's still the obvious choice
None of this is an argument against WordPress — we still ship it regularly. A marketing site, a blog-heavy content business, a small business site where the owner wants to edit their own hours and photos: WordPress with a clean, minimal plugin footprint is still faster to build, cheaper to maintain, and easier to hand off than a custom build. The mistake was treating it as the default for everything else too.
For anything with real application logic — booking systems, account-gated content, custom dashboards — we now lean toward a proper front end (React, in most of our work) talking to a purpose-built backend, even if it takes longer to get the first version live. The difference shows up six months later, not on launch day, which is exactly the kind of trade-off that's easy to miss when you're just trying to hit a deadline.
The migration question nobody asks upfront
The other conversation we have more often now is what happens if the client outgrows whatever we build. A WordPress site that's stayed lean — theme, a handful of well-chosen plugins, no page builder bloat — is genuinely easy to migrate away from later if the business needs change. A WordPress site propped up by a dozen interacting plugins is much harder to leave, because untangling which plugin is responsible for which piece of functionality becomes its own project. We now factor that exit cost into the recommendation, not just the cost of getting to launch.
That's also why, when we do build on WordPress, we're stricter than we used to be about plugin choices. Every plugin is a piece of code we didn't write and don't control the update schedule for, and each one is a new dependency that can break on a core update. We'd rather write forty lines of custom code for a specific feature than add a plugin that solves that feature plus twenty others the client will never use.
If you're mid-decision on this for your own project, the honest version of our advice is: tell us what changes on the site every week, and who's making that change. That answer tells us more than the feature list does.
