Why I Stopped Calling Myself a “Web Developer”

The problem with “web developer” as an identity

The phrase “web developer” describes a tool you use, not a problem you solve. It’s the equivalent of a surgeon introducing themselves as “someone who uses scalpels.” Technically true. Completely misses the point.

When you call yourself a web developer, you’re signaling to the market that you build things — and the market prices that accordingly. You become a commodity. Clients compare you to the next developer on Upwork with a lower hourly rate. Conversations start with “how much per hour?” instead of “what would this system do for my business?”

“Web developer” tells people what you use. It says nothing about what you solve. And clients don’t pay for tools. They pay for solutions.

I noticed this clearly when I looked at my client conversations. The ones where I said “I’m a web developer” almost always turned into price negotiations. The ones where I explained what I actually built — a WooCommerce system that automated their order workflow, a WordPress dashboard that showed them real business data — those turned into long-term relationships at much better rates.

The title was costing me money and positioning me wrong in every conversation I had.

What I actually do

When I looked honestly at my project history, I noticed something. The work I was most proud of — and the work clients valued most — wasn’t the code itself. It was what the code replaced.

I replaced a client’s spreadsheet-based order system with a custom WooCommerce workflow. They stopped spending 12 hours a week manually processing orders. That’s not web development. That’s operational transformation.

I built a booking system for a service business that integrated with their calendar, sent automatic confirmations, and handled payment upfront. Their no-show rate dropped significantly. Their admin workload nearly vanished. That’s not a website. That’s a business system.

I rebuilt a WooCommerce store’s product option architecture so customers could customize products without calling the shop. The store’s average order value went up. That’s not plugin installation. That’s revenue engineering.

The moment I started describing my work by what it changed rather than how I built it, everything shifted — my pricing, my clients, and my own sense of what I was doing.

Once I saw this pattern, the new title was obvious: product engineer. Someone who builds systems that solve business problems — not someone who writes code for a living.

The practical differences between the two identities

This isn’t just a branding exercise. The title you carry shapes how you approach every project. Here’s what actually changed for me when I made the shift.

How I think about a new project

As a web developer, my first question was: “What do you need me to build?” I was waiting for a spec. My job was execution.

As a product engineer, my first question is: “What business problem are we solving?” I ask about current workflows, where time is being wasted, what’s breaking, what growth is being held back. I often spend more time in conversation and documentation before I write a single line of code.

How I scope and price work

Web developers price by hours or deliverables. “I’ll build you a 5-page website for $800.” The client knows exactly what they’re getting, and they compare it to the next developer’s $600 quote.

Product engineers price by scope and value. “I’ll build you a WooCommerce system with automated order processing, a custom admin dashboard, and a customer portal — and here’s what it’ll do for your operations.” That conversation doesn’t start with “how much?” It starts with “when can you start?”

How I talk about technology

Web developers talk about what they use: React, PHP, Gutenberg, REST API. These are genuinely exciting to us. They mean almost nothing to a business owner.

Product engineers talk about what the technology does: “This will let your team see real-time order data without logging into WooCommerce. This will automatically notify customers when their order status changes. This will cut your weekly reporting from three hours to fifteen minutes.”

The technology is still the same. The conversation is completely different.

“But I don’t have a product”

When I talk about this shift, developers often push back: “That title only works if you’re building your own product. I do client work.”

This misunderstands what product engineering means. A product engineer thinks about systems the way a product designer thinks about user experience — as something that needs to be scalable, maintainable, and built around the person using it. That applies whether you’re building a SaaS product or a custom WooCommerce workflow for a Bangladesh retail business.

Every system I build for a client is a product. It has users. It solves a problem. It needs to work reliably without me being there to hold it together.

That said — I am building products now. Real ones, on wpagain.com. The identity shift is what led me there. Once you start thinking like a product engineer, you start seeing the problems that need products, not just the clients that need developers.

What changed in practice

I want to be specific here, because vague “mindset shift” posts don’t help anyone. These are the concrete things that changed when I changed how I identified my work.

• My discovery process got longer and more valuable.
• My proposals changed from feature lists to business outcomes.
• I started building architecture documentation before writing code.
• I started saying no to more projects that were not the right fit.
• My work became more interesting because I was solving problems, not only executing tasks.

The deeper question underneath all of this

Here’s what I’ve come to believe: most developers who feel undervalued, underpaid, or stuck are suffering from a positioning problem, not a skills problem. They’re exceptional at the craft. They’re describing themselves in terms that make the craft invisible.

The work of building something that changes how a business operates is remarkable. It should be described as remarkable. “Web developer” doesn’t do that. “Product engineer who builds WordPress systems that help businesses operate better” — that describes something worth paying for.

I’m not saying the title is magic. The thinking has to change too. But the title forces the thinking. When you call yourself a product engineer, you can’t answer “what do you need built?” without first asking “what are you trying to achieve?” The label creates an obligation to the identity.

That obligation changed my work. I think it’ll change yours too.