The plugin passed acceptance on a clean install and took the client's checkout down four days later — WooCommerce shipped 8.2, a hook we depended on moved, and a fatal error hit the same code path that ran the payment confirmation. The demo lied because the demo was one site, one theme, and zero other plugins fighting for the same hooks. Production was WooCommerce, Elementor, an object cache, and eleven other plugins all registered against `init` and `the_content`, and that is where the bugs that cost money live. A vendor who has only built against clean installs hands you something that reviews well and breaks on the first minor version bump.
This is the article we wish more buyers read before they sign a plugin contract. WordPress is not hard in the abstract — the Hooks API, `$wpdb`, and the REST layer are mature and well-documented. The failures are boring and specific: a duplicate class name, an autoloaded option, a `permission_callback` left wide open. Boring and specific is exactly what cheap plugin work skips, and it is exactly what wrecks a site that touches your data, your checkout, or your users.
Prefix everything or watch it collide
The most common thing we inherit is a plugin that declares `function get_settings()` or `class Cache` in the global namespace. PHP has no module boundary here, so the second plugin to declare that symbol throws `Cannot redeclare`, and the site that was fine yesterday is a white screen with a 500 today — no gradual degradation, just gone. The fix is unglamorous: namespace the entire plugin, prefix every option key, post-meta key, and custom table with something nobody else will pick, and never assume a name is free because it happened to work on your laptop.
The autoloader is the trap people miss. Bundle Guzzle 7 with a naive Composer autoloader, and a second plugin bundles Guzzle 6 — whichever registers first wins, and the other plugin now runs its calls against a class with a different method signature and fails in ways that make no sense in the stack trace. We scope vendor dependencies with php-scoper, rewriting the namespaces to something like `Duskel\Vendor\GuzzleHttp` at build time, so our copy cannot be shadowed by anyone else's. It is ten minutes of tooling that deletes a category of bug you would otherwise spend a day bisecting in production.
Hooks are a contract, and priority matters
Actions and filters only cooperate if everyone agrees on timing, and priority 10 — the default — is where every plugin piles up, so execution order collapses to registration order you do not control. If your filter rewrites a query another plugin already rewrote at priority 10, the winner is whoever `require`d first. We set priority on purpose: run at 999 when we need the last word on `the_content`, run at 1 when we are seeding defaults, and never do expensive work on `init` that belongs on `template_redirect` or a cron event where it runs once instead of on every request.
The other half is blast radius. A `pre_get_posts` handler without `is_admin()` and `$query->is_main_query()` guards fires on every secondary loop, every widget, every admin list table. We debugged a site whose search results were wrong for months because one plugin's query filter had no `is_main_query()` check and quietly reordered every archive on the site. Scoping a hook to the one condition you actually mean is the line between a feature and a landmine that goes off in someone else's code.
Your database schema is forever
The moment you write a custom table or a batch of post-meta, you own a migration path you cannot walk back. Version 2 needs a new column, and now you need a migration that runs exactly once, is idempotent, and does not hit `max_execution_time` on a table with two million rows. We store a `db_version` option, gate each migration behind a version comparison, and push large backfills into batched Action Scheduler jobs — 500 rows a batch — instead of an inline `ALTER TABLE` on activation that locks the table and 504s the moment the site is big enough to matter.
Storage decides your performance ceiling before traffic ever does. Drop a large array into `wp_options` with `autoload` set to `yes` and every page load unserializes it whether the request needs it or not; we have watched one bloated autoloaded option add 300ms to every request site-wide, homepage to admin. Custom tables with the right indexes, `autoload` set to `no`, and reads that check `wp_cache_get` before touching MySQL are not premature optimization — they are why the plugin still answers when the client's Black Friday traffic triples.
Security is the part nobody sees until it's too late
Every input is an attack surface, and skipping the guardrail costs nothing until it costs the whole database. Form handlers need a nonce to stop CSRF, a `current_user_can()` check to confirm the user is allowed, sanitization in, and escaping out. REST and admin-ajax endpoints are the reliable soft spot: a vendor sets `permission_callback` to `__return_true` because it was convenient during testing, ships it, and now any unauthenticated request on the internet can call it. We treat that callback as non-negotiable and escape at output even for rows we wrote ourselves, because the plugin that trusts its own table is the one that serves stored XSS the day someone smuggles a `<script>` past a form you forgot to sanitize.
Unprepared SQL is the other recurring wound. `$wpdb->prepare()` exists so user input never lands in a query string by concatenation, yet SQL injection through interpolated `$wpdb->query()` calls is still near the top of the WordPress plugin CVEs disclosed every year. None of this is exotic — it is a checklist. The only variable is whether your vendor runs it on every endpoint or only on the ones someone happened to review.
How to tell before you hire
Ask how they ship an update to a site they do not control — if the answer is not a staging clone and a tagged rollback, keep looking. Ask what happens to the custom tables on deactivate versus delete, because a vendor who has an uninstall.php answer has thought about the full lifecycle instead of just the happy path. Ask how they scope dependencies, whether their CI runs against the current and previous WooCommerce and WordPress releases, and how errors reach a log instead of `display_errors` dumping a stack trace to a customer. The good ones answer in one breath because these are the fights they have internally; the cheap ones pivot to how many plugins they have shipped.