8 Red Flags When Hiring a WordPress Developer (Before You Sign Anything)

Red flag 1: A quote that arrived before any questions were asked

If a developer sends you a price within hours of your first message — without asking about your current setup, your integrations, your payment gateway, your performance baseline — they priced a generic project. Not your project.

Custom WordPress work has too many variables to quote without discovery. What plugins are already installed? Is there an existing database that needs migrating? Does your WooCommerce store require a specific payment gateway for your market? Is this a full rebuild or an extension of existing work?

A fast quote is not efficiency. It is a signal that the developer plans to deliver something generic and call it done. The discovery conversation is where a good developer earns their fee — before they charge it.

Red flag 2: A portfolio of screenshots with no live URLs

Screenshots prove nothing. A screenshot can be lifted from a theme demo, generated by AI, or taken of a site the developer had nothing to do with. Anyone can right-click and save.

The only portfolio entry that matters is a live URL you can audit. Open it in PageSpeed. Check whether the site loads under 3 seconds on mobile. Look at the source — is it clean or is it five page-builder plugins stacked on top of each other?

If a developer cannot share a single live URL, ask why. "The client wanted it private" is plausible once. Every time is a pattern.

Red flag 3: They cannot explain what they will build — only what it will look like

Ask any developer: "Walk me through how you would handle [the specific technical requirement on your project]." For a WooCommerce store: how would you handle inventory sync if we have a POS system? For a membership site: how does the access logic work when a subscription lapses?

A developer who can answer this is thinking about your system. A developer who pivots to showing you theme options is thinking about their deliverable.

Visual design is reproducible. Architecture decisions — what gets cached, how the database is structured, where the bottlenecks are — are not. The conversation about the technical approach tells you which kind of developer you are talking to.

Red flag 4: No mention of performance until you bring it up

A 0.1-second improvement in mobile load time increases retail conversions by 8.4%, according to Google's research. A developer who does not mention Core Web Vitals, caching strategy, or image optimisation in a sales conversation has not built sites where performance was a priority.

This is not about expecting every developer to obsess over milliseconds. It is about whether they are aware that performance is a business metric, not just a technical one. If it does not come up naturally in the conversation, ask directly: "What is your approach to Core Web Vitals on a new build?" The answer will tell you everything.

A correct answer includes: measuring before touching anything, a caching layer (Redis or object cache), image format strategy (WebP/AVIF), and a plan for render-blocking scripts. A vague answer about "optimising later" is the flag.

Red flag 5: The proposal has no deliverable specifications

"A fully functional WordPress website" is not a specification. It is a starting point for a dispute. What pages? What integrations? What does "fully functional" mean when the client expects a custom checkout flow and the developer planned a default WooCommerce setup?

Scope ambiguity is not accidental. Vague proposals protect the developer, not the client. When the build is finished, anything not written down becomes a "change request" — which costs extra.

A good proposal names every page, every integration, every plugin, every custom feature. It lists what is explicitly out of scope. It defines what "done" means in measurable terms — live, passing PageSpeed threshold, tested in both major browsers. If the proposal you received cannot answer "is X included?", the answer is probably no, and you will find out the hard way.

Red flag 6: They cannot tell you who will actually build your site

Ask: "Who specifically will write the code on my project?" If you are talking to an agency or a broker, the answer matters. The senior developer who pitched you is not necessarily the person at the keyboard. Mid-size projects are typically handed to junior developers, with the senior reviewing deliverables — not writing them.

This is not inherently wrong. But if you are paying senior rates and expecting senior judgment, you should know whether you are getting it.

With a freelancer, the answer is immediate: the person you are talking to is building the site. With an agency, push for a name and a brief on their experience. A good agency will introduce you before the contract. One that cannot — or will not — is selling you a brand, not a person.

Red flag 7: No plan for what happens after launch

WordPress requires active maintenance. Plugin vulnerabilities are discovered regularly. Core updates break things. A site that worked perfectly on launch day will have issues by month three if no one is watching it.

A developer who has no answer to "what happens after the site goes live?" is delivering a project, not building a product. Ask directly: do they offer a maintenance retainer? What does it include — updates, uptime monitoring, backup verification, performance checks? What is the response time if something breaks?

The absence of any post-launch plan is not just a service gap. It signals that the developer builds sites and moves on — which means when something breaks, you are calling a stranger who has already forgotten your project.

Red flag 8: The price is significantly below every other quote

This one is last because it is the most obvious — and yet it keeps working. A price that is 60% cheaper than three other quotes is not a bargain. It is a different product.

The cost of cheap WordPress development is not the upfront price. It is the rebuild cost twelve months later when the site is breaking under real traffic, the security audit after the plugin vulnerability, and the developer hours spent understanding code that was written without any architecture in mind.

The pattern: a cheap site is built fast using a heavy page builder, twenty generic plugins, and no performance consideration. It looks fine on launch. Six months later, it fails a Core Web Vitals audit, a plugin update breaks the checkout, and the developer is unreachable. The client pays twice.

Price signals risk, not greed. When multiple experienced developers quote a similar range, that range reflects the actual complexity of the work. A quote far below that range reflects a developer who either does not understand the complexity — or does not plan to address it.