Why I Only Do WordPress Even Though AI Lets Me Do Everything

A few weeks ago, one of my project managers asked me a question I’ve heard at least a dozen times in the last year.

“Varun bhai, why don’t we just take that Shopify project? We could figure it out. And that mobile app inquiry – we could handle it too.”

I smiled. Because I remember when I used to think the same way.

When you run a WordPress agency and you’ve built over a hundred plugins, when you’ve worked with BuddyPress since before most people knew what community platforms were, when you’ve seen WordPress grow from a blogging tool to powering 43% of the web – you develop a certain confidence. And that confidence sometimes whispers: “You could do anything.”

And here’s the thing – with AI, that whisper has become a shout.

Today, I genuinely believe I could build a decent Laravel application. I could ship a React Native mobile app. I could take on a Shopify project and deliver something reasonable. AI has made all of that technically possible. The “how” is no longer the barrier.

But I still said no to that Shopify project. And I’ll keep saying no.

This post is about why. Not because I’m against growth or expansion – but because I’ve learned that building something is the easy part. It’s everything that comes after that separates the professionals from the pretenders.

The Question That Keeps Coming Back

Let me set the scene properly. I run Wbcom Designs. We have a team – developers, project managers, support staff. We maintain over a hundred WordPress plugins. We serve thousands of customers. And every quarter, someone on the team brings up the same idea.

“Why are we limiting ourselves to WordPress?”

The argument always sounds logical. A client comes to us wanting a Shopify store. Another wants a Flutter mobile app. Someone else needs a custom Laravel backend. The team sees these as opportunities we’re leaving on the table. Revenue we’re walking away from.

And I get it. From a business perspective, saying no to money feels counterintuitive. Especially when the client already trusts you and wants YOU to do it.

But here’s what I tell my team every single time, and I’ll share it with you exactly the way I say it:

“I am a 100% WordPress expert. If my lead developer gets stuck on a WordPress problem at 2 AM, I can open my laptop and help them figure it out. I can look at the code, understand the architecture, trace the hook, find the bug. But if we take on a Laravel project and the developer gets stuck? We’re ALL stuck. There’s no safety net. There’s no one to escalate to. The buck stops with me, and I won’t know how to fix it.”

That’s not humility. That’s honesty. And there’s a massive difference between the two.

Why This Matters More Than Ever in the AI Era

Now, here’s where things get interesting – and where I suspect some of you might disagree with me.

AI has fundamentally changed what’s technically possible for a small team. I’m not being theoretical here. I use AI tools every single day in my work. Claude helps me write code. It helps me debug. It helps me think through architecture decisions. It helps me write content (yes, including helping me organize my thoughts for posts like this one).

And because of AI, the technical barrier to entering a new technology domain has dropped dramatically. Give me Claude, give me a weekend, and I could probably scaffold a decent Laravel application with proper MVC architecture, migrations, middleware – the whole thing.

This is the distinction that too many people miss in the current AI hype cycle. Yes, AI lets you build things in technologies you’ve never used before. But building is maybe 20% of the job. The other 80% is:

• Supporting it when clients have issues
• Maintaining it as the underlying platform evolves
• Debugging it when something breaks in production at midnight
• Scaling it when the client’s business grows
• Securing it against vulnerabilities you didn’t even know existed in that ecosystem
• Knowing the community – the plugins, the patterns, the gotchas, the workarounds

AI can help you write the code. But can AI take a support call from a frustrated client? Can AI troubleshoot a server configuration issue specific to their hosting provider? Can AI tell you that a particular WooCommerce extension has a known conflict with a specific payment gateway in certain currency configurations?

No. That’s experience. That’s expertise. That’s the stuff that takes years to build and can’t be shortcut.

The Logic Was Always There – AI Just Answered the “How”

Let me give you a framework for understanding this.

Every project has two layers:

1. The “What” and “Why” – What needs to be built, why it needs to work this way, what the business requirements are, what the edge cases are, how the user will actually interact with it.
2. The “How” – The actual implementation. Writing the code. Choosing the right function. Structuring the database. Connecting the APIs.

Here’s what AI changed: it almost entirely answered the “How” layer. If you know what you want to build and why, AI can tell you how to build it in almost any technology.

But AI did NOT change the “What” and “Why” layer. That still requires:

• Domain expertise
• Understanding of the ecosystem
• Knowledge of how things fail (not just how they work)
• Years of pattern recognition from supporting real users
• The ability to scope correctly because you’ve seen what happens when you scope badly

I know WordPress. I know it inside and out. I know what happens when you have a plugin conflict with a custom post type that uses a meta query with multiple orderby parameters on a multisite installation with object caching enabled. I’ve been through that exact scenario. Multiple times.

Could I ask AI how to solve a similar problem in Laravel? Sure. Would the answer probably be technically correct? Probably. But would I have the intuition to know which of the five “correct” approaches is actually the right one for this specific situation? No. Because intuition comes from experience, not from documentation.

The Reddit Thread That Proved My Point

A few weeks ago, a thread blew up across both r/WordPress and r/webdev. The title was devastating in its simplicity:

“Paid in full for a website that was never delivered – developer has gone silent.”

The post gathered over 160 comments across both subreddits. And while the surface story was about a developer who took money and disappeared, the deeper lesson was about something else entirely: overextension.

Reading through the comments, a pattern emerged. Many of the developers who end up in these situations – ghosting clients, delivering half-finished work, going silent – aren’t scammers. They’re overextended. They took on projects they couldn’t handle. They bit off more than they could chew. Maybe they were great at one thing but took on a project in a technology they were still learning.

One commenter put it perfectly: “Most devs who ghost aren’t malicious. They’re in over their heads and too embarrassed to admit it.”

That hit home for me. Because I’ve seen this in our industry for fifteen years. A WordPress developer takes on a custom React project because the money’s good. A freelancer who’s great at static sites accepts a complex e-commerce build. A designer who’s been learning to code takes on a full application development project.

The intention is good. The capability might even be there – especially now with AI. But the support infrastructure isn’t. The experience isn’t. The safety net isn’t.

And the client pays the price.

I Am Not Doing Lots of Half-Cooked Things

This is something I say to my team regularly, and I want to share it here because I think it’s one of the most important principles in running a sustainable tech business:

Half-cooked means:

• A project you can build but can’t support
• A plugin you can launch but can’t maintain
• A technology you can code in but can’t debug in
• A promise you can make but can’t keep

The temptation to half-cook things has never been higher. Because AI makes the cooking so fast. You can prototype a mobile app in a day. You can scaffold a SaaS application in a weekend. You can generate code in a language you’ve never written before and it’ll actually compile and run.

But here’s what nobody talks about: Day 1 is easy. Day 100 is what separates the businesses that survive from the ones that don’t.

On Day 1, you ship the project. The client is happy. You feel great. You think: “Why was I so worried? AI made this easy!”

On Day 30, the client reports a bug. It’s in a part of the codebase you don’t fully understand because AI wrote it. You ask AI to fix it. AI suggests something. You deploy it. It seems to work.

On Day 60, there’s a security vulnerability in the framework you used. You’re not subscribed to their security mailing list because you don’t actually follow that ecosystem. You don’t know about it until the client’s site gets compromised.

On Day 100, the client wants a new feature. It requires understanding the architecture deeply. You’ve moved on to other projects. The codebase is a black box. AI wrote most of it, and the design decisions it made don’t match how you’d think about the problem – because you don’t think in that technology’s patterns.

This is the lifecycle of a half-cooked project. And it’s becoming more common, not less, as AI makes Day 1 easier.

The Three Pillars of Responsible Expertise

Over the years, I’ve developed a simple test for whether we should take on a project. It has three questions:

1. Can I Be Confident in It?

Confidence here doesn’t mean “I think I can build it.” It means: “I am certain I can deliver it to a standard I’m proud of, handle edge cases, and deal with the unexpected.”

In WordPress, I’m confident. If a client comes to me with a complex BuddyPress community platform, I don’t just think I can do it – I know I can. Because I’ve done it dozens of times. I know where the pitfalls are. I know which approach will scale and which will become a nightmare at 10,000 users.

In React Native? I could build it with AI. But would I be confident? Honestly, no. There’s a difference between “I can make this work” and “I know this will work in production for the next two years.” Confidence comes from repetition, from failure, from learning the hard way what doesn’t work.

2. Can I Give Support for It?

This is the one most people skip. Building is glamorous. Support is not. But support is where businesses are made or broken.

When a client sends us a support ticket for one of our WordPress plugins, we can usually diagnose the issue within minutes. Not because we’re geniuses, but because we’ve seen that exact issue – or something very similar – hundreds of times. We know the common causes. We know the quick fixes. We know when it’s our bug and when it’s a conflict with another plugin.

That support muscle takes years to develop. AI can help you respond to tickets faster, but it can’t replace the institutional knowledge that comes from years of working in one ecosystem.

If we took on Shopify projects, we’d be starting from zero on support knowledge. Every issue would be a research project. Every bug would take 3x longer to diagnose. And the client would feel it – because response times would be slower, solutions would be less confident, and we’d be guessing more than knowing.

3. Can I Maintain It Long-Term?

This is the big one. The one that separates agencies that last fifteen years from the ones that last fifteen months.

WordPress updates four times a year. PHP versions evolve. Hosting environments change. Browser standards shift. Every time WordPress releases a major update, we test our plugins against it. We know what’s likely to break. We know which deprecated functions we need to update. We have automated tests. We have a process.

Could we build a Laravel application? Yes. Could we maintain it for five years, keeping it updated with Laravel’s release cycle (which is aggressive), patching security issues, staying current with PHP standards specific to the Laravel ecosystem? That’s a completely different question. And the honest answer is: not to the standard I’d be comfortable with.

Maintenance is a commitment. It’s not a one-time task. It’s a relationship. And just like any relationship, it only works if you’re fully invested.

But Varun, Aren’t You Just Leaving Money on the Table?

This is the pushback I always get. And I understand it. Let me address it head-on.

Yes, in the short term, we’re saying no to revenue. That Shopify project could have been worth $20,000. That mobile app inquiry might have been a $50,000 contract. By my team’s calculation, we probably turn down $100,000+ in non-WordPress work every year.

But here’s what we DON’T lose:

• Our reputation for quality WordPress work
• Our ability to support every product we ship
• Our sanity (seriously – scope creep into unfamiliar tech is a mental health nightmare)
• Our existing clients’ trust, which comes from knowing we’re focused on being the best at one thing
• Our team’s expertise, which deepens with every WordPress project instead of diluting across five technologies

There’s a concept in business strategy called the “focus dividend.” When you focus on one thing, you get better at it exponentially faster than if you split your attention. Our WordPress knowledge compounds. Every plugin we build teaches us something that makes the next one better. Every support ticket we handle makes us faster at diagnosing the next one.

If we split our attention across WordPress, Shopify, Laravel, and mobile apps, none of that compounding happens. Instead of being world-class at one thing, we’d be mediocre at four things.

And here’s the ultimate irony: by being known as the WordPress experts, we actually get MORE WordPress work than we would if we marketed ourselves as a “full-stack, any technology” agency. Specialization attracts premium clients who value depth over breadth.

The Self-Employment Trap

Another thread that caught my eye on r/webdev was about self-employment. The discussion was fascinating because it revealed a pattern I see constantly: freelancers and small agencies who expand into new technologies because they feel they HAVE to in order to stay competitive.

“If I don’t offer mobile apps, I’ll lose clients to agencies that do.”

“If I only do WordPress, people will think I’m limited.”

“AI lets me offer everything now – why wouldn’t I?”

This is fear-driven decision making, and it almost always leads to the half-cooked outcome I described earlier. You don’t expand into new technologies because clients demand it. You expand only when you’ve built the expertise, the support infrastructure, and the long-term maintenance capability to back it up.

A relevant post on r/SaaS had an even sharper angle. It argued that the “side project” era is dead – that solo founders are now basically micro-startups. And while I don’t fully agree with that framing, the underlying point is important: whatever you build, you need to treat it as a real commitment, not a side experiment. The bar for quality, support, and maintenance keeps going up, not down.

AI makes it easier to START things. It does not make it easier to SUSTAIN things.

What AI Actually Changed (and What It Didn’t)

Let me be very clear about something: I’m not anti-AI. Far from it. AI has transformed how I work. It’s made me significantly more productive within my domain of expertise.

Here’s what AI genuinely changed:

• Speed of implementation – What used to take a week now takes two days
• Code quality within familiar domains – AI catches bugs I might miss and suggests patterns I might not have considered
• Learning efficiency – When I need to understand a new WordPress API or a recent PHP feature, AI explains it faster than documentation
• Documentation and communication – AI helps me write better docs, better proposals, better client communications
• Problem-solving breadth – AI offers approaches I might not have thought of, drawing from patterns across the entire programming world

Here’s what AI did NOT change:

• The need to understand what you’re building – AI can write code, but YOU need to know if it’s the right code
• The support burden – Clients don’t care if AI wrote it; they need a human who can help them when it breaks
• The maintenance commitment – Software doesn’t maintain itself, and AI isn’t watching your production servers at 3 AM
• The reputation risk – If you ship garbage, your name is on it, not AI’s
• Domain expertise accumulation – You still need years of experience to develop intuition, and AI can’t fast-track that

I think of AI as a force multiplier. If your expertise is a 9 out of 10, AI makes you an 11. If your expertise is a 2 out of 10, AI might make you a 4. But that 4 is still not good enough for production work that clients are paying for and depending on.

AI is a force multiplier. A 9 x AI = 11. A 2 x AI = 4. But production work demands at least an 8. There’s no shortcut past that threshold.

The Real Danger: The Overconfidence Trap

Here’s what I think is the most dangerous trend right now. AI creates a very convincing illusion of competence.

You can ask AI to build you a Laravel application, and what you get back will look professional. It’ll have proper structure. It’ll follow conventions. It’ll have error handling and validation. On the surface, it looks like something a senior Laravel developer built.

But it’s an illusion. Because while the code LOOKS competent, the decisions behind it aren’t informed by experience. AI doesn’t know your specific use case the way an experienced developer would. It doesn’t know that this particular database schema is going to cause performance issues at scale. It doesn’t know that this authentication approach has a known vulnerability in certain configurations.

And the most dangerous part? Because the code looks good, you might not even realize what’s missing until it’s too late.

This is exactly what I mean when I say “building is easy.” AI can make anything look good on Day 1. But the cracks appear on Day 30, Day 60, Day 100. And by then, the client has invested money, their business depends on it, and you’re in a position where you can either admit you’re in over your head or try to bluff your way through.

Neither option is good. Both damage your reputation. Both hurt the client.

The responsible choice is to never put yourself in that position in the first place.

How I Think About the 7-Page Website Question

There was an interesting thread on r/ProWordPress asking how long it takes to build a 7-page WordPress site. The answers ranged wildly – from “a few hours” to “several weeks.” And that range tells you everything about the difference between building and DOING IT RIGHT.

A 7-page WordPress site with AI could be “built” in a few hours. Templates, content, basic styling – done. Ship it.

But is it accessible? Is it optimized for Core Web Vitals? Is the contact form secure? Does the SEO structure make sense? Is the hosting configured properly? Is there a backup strategy? Is the security hardened? Does the client know how to manage content? Is there documentation?

All of those questions require expertise. Not AI. Not templates. Not speed. Expertise.

I can answer all of those questions for WordPress, confidently, because I’ve done it thousands of times. Could I answer them for a Shopify store? Maybe some of them. Could I answer them with the same confidence? Absolutely not.

And confidence matters. When a client asks me “Is my WordPress site secure?” I can look them in the eye and say yes, and explain exactly why. That certainty is worth more than any amount of AI-generated code.

The Partnership Model That Actually Works

Now, saying no to non-WordPress work doesn’t mean turning clients away entirely. Over the years, we’ve built a network of trusted partners for exactly this situation.

Client needs a mobile app? I know a team that specializes in Flutter. They’re the mobile equivalent of what we are for WordPress. I make the introduction, we handle the WordPress API side, they handle the mobile side. The client gets two expert teams instead of one team that’s expert in one thing and guessing at the other.

Client needs a Shopify store? I have contacts who eat, sleep, and breathe Shopify. They know the ecosystem like I know WordPress. They’ve debugged the same Shopify issue a hundred times. They can provide real support.

This partnership model means:

• The client gets expert-level work on every part of their project
• We maintain our focus on what we do best
• Our partners get business they’re perfectly suited for
• Nobody is half-cooking anything

It’s slower to set up. It requires trust. It means giving up control (and revenue) for parts of the project. But the outcome is dramatically better for everyone involved, especially the client.

What I’d Tell My Younger Self

If I could go back and talk to 25-year-old Varun, the one who was just starting out in WordPress, here’s what I’d tell him:

“You’re going to be tempted to say yes to everything. Every project that comes through the door is going to look like an opportunity. A Joomla site here, a Drupal project there, maybe a custom PHP framework project that pays really well.”

“Say no. Not because those are bad technologies. Not because you can’t learn them. But because every hour you spend learning a new technology is an hour you’re NOT spending becoming exceptional at WordPress.”

“And exceptional is where the magic happens. Exceptional is what gets you referrals. Exceptional is what lets you charge premium rates. Exceptional is what makes clients trust you with their most important projects.”

“Good enough doesn’t build careers. Exceptional does.”

Every hour you spend learning a new technology is an hour you’re NOT spending becoming exceptional at the one you’ve chosen. And exceptional is where the magic happens.

I’d tell him that AI is coming, and it’s going to make it even harder to stay focused. Because AI will make every technology feel accessible. It’ll make you feel like you can do anything. And technically, you CAN.

But CAN is not the same as SHOULD.

The Modern Developer’s Discipline Challenge

I think the biggest challenge for modern developers isn’t technical. It’s not “can I learn this technology?” Because with AI, the answer to that is almost always yes.

The biggest challenge is discipline.

The discipline to say: “I could do this, but I’m going to pass it to someone who does it better.”

The discipline to say: “This project looks profitable, but it’s outside my expertise, and the client deserves better than my best guess.”

The discipline to say: “AI can build this for me, but I can’t support it, maintain it, or stand behind it the way I stand behind my WordPress work.”

In a world where AI makes everything buildable, discipline becomes the competitive advantage. The developers and agencies who thrive won’t be the ones who build everything. They’ll be the ones who build the RIGHT things – deeply, excellently, and with the full commitment to support them for years to come.

A Word on “Jack of All Trades”

I know someone is going to read this and think: “But what about full-stack developers? What about generalists? Aren’t they valuable too?”

Absolutely. Generalists play an important role, especially in startups and small companies where one person needs to wear many hats. I’m not arguing against generalism in principle.

What I’m arguing against is dishonest generalism – claiming expertise you don’t have, taking on work you can’t support, and using AI to paper over gaps in your knowledge that will eventually hurt the client.

If you’re a genuine full-stack developer with deep experience across multiple technologies, that’s amazing. You’ve put in the years. You’ve built the support muscle in each technology. You can debug a React component AND a Rails controller with equal confidence. That’s real expertise.

But if you’re a WordPress developer who’s using AI to “also do” Laravel and mobile and Shopify and whatever else comes through the door – that’s not generalism. That’s overextension. And your clients will eventually pay the price for it.

My Rules for Expansion (If You Must)

Look, I’m not saying you should never expand into new technologies. I’m saying you should do it responsibly. Here’s my framework:

Rule 1: Don’t Expand Until You Can Hire an Expert

If you want to add mobile app development to your agency’s offerings, don’t just learn it yourself with AI. Hire someone who lives and breathes mobile development. Someone who can be the safety net. Someone who can debug production issues without asking AI for help. Someone whose expertise you can escalate to.

Rule 2: Run It Internally for Six Months Before Offering It to Clients

Build internal projects in the new technology first. Experience the maintenance burden. Hit the edge cases. Learn what breaks and how to fix it. Only after six months of running a real project should you even consider offering it externally.

Rule 3: Start with Hybrid Projects

If you’re a WordPress agency wanting to add mobile, start with projects that are WordPress-heavy with a thin mobile layer. Don’t jump straight into fully native mobile apps. Build your support muscle gradually.

Rule 4: Be Transparent with Clients

If you’re new to a technology, tell the client. “We’re expanding into this area. We have strong developers but less experience than in our core WordPress work. Here’s how we’re mitigating the risk.” Most clients respect honesty more than false confidence.

Rule 5: Have an Exit Plan

Before starting any project in a new technology, have a plan for what happens if it goes wrong. Can you bring in a specialist? Can you partner with an expert agency? Can you refund the client and help them find a better fit? Never start a project without knowing your escape route.

The WordPress Opportunity Is Bigger Than Ever

Here’s the irony that I’ll close with. While everyone is chasing the next shiny framework, the WordPress market is bigger and more lucrative than it’s ever been.

WordPress still powers 43% of the web. The plugin market is worth billions. Enterprise WordPress is growing. Headless WordPress is opening up new architectural possibilities. The block editor is maturing into a legitimate application framework. WooCommerce processes billions of dollars in transactions.

There is more WordPress work available right now than there are expert WordPress developers to do it. The market is not shrinking. It’s growing. And the developers who are leaving WordPress to chase other technologies? They’re creating opportunities for those of us who stay and deepen our expertise.

I’m not worried about WordPress’s future. I’m not worried about AI replacing WordPress developers. I’m not worried about the next hot framework.

I’m focused on doing what I do best, better than I did it yesterday. And using AI not to expand into new territories, but to go deeper into the territory I’ve already claimed.

The Bottom Line

AI has given us a superpower: the ability to build anything. But superpowers come with responsibility. And the most important responsibility is knowing when NOT to use them.

I can build anything now. But I choose to build only what I can support, maintain, and stand behind. That’s not limitation. That’s discipline. That’s professionalism. That’s how you build something that lasts.

The developer who takes on every project because AI makes it possible will burn bright for a year, maybe two. Then the support tickets pile up. The maintenance becomes overwhelming. The quality drops. The reputation suffers. And eventually, they become another “developer has gone silent” Reddit thread.

The developer who sticks to their expertise, who uses AI to go deeper rather than wider, who says no to the easy money and yes to the right work – that developer builds a career. A business. A reputation. Something that lasts.

I know which developer I want to be. I’ve made my choice. And fifteen years into WordPress, I’ve never been more confident that it was the right one.

AI lets you build anything. Discipline means building only what you can own – completely, confidently, and for the long haul. That’s not a limitation. That’s a competitive advantage.

So the next time someone asks me why I only do WordPress, I’ll smile and give them the same answer I always do:

“Because I’d rather be exceptional at one thing than half-cooked at five.”

And then I’ll open Claude, pull up my WordPress project, and get back to work on what I do best.

---

What about you? Have you been tempted to expand into new technologies just because AI makes it possible? Have you made the leap and regretted it – or loved it? I’d genuinely love to hear your perspective. The smartest people I know are the ones who’ve thought hard about where their boundaries should be. Drop a comment or reach out – I’m always up for this conversation.

Related Reading

• Claude’s 1M Context Window and WordPress: What Actually Changes for Developers
• WordPress Coding Standards: Why I Enforce WPCS on Every Project
• MCP Servers for WordPress Developers: The Tools I Actually Use Every Day