The 5D Enterprise WordPress Framework™

What I find in the audit shapes the entire engagement. Hardcoded credentials in the theme. Plugins three major versions behind. Custom functions that override WordPress core in ways nobody documented. A child theme that breaks if you update the parent.

The Ministry of Education Ontario engagement started with a full codebase audit. What we found - an editorial workflow partially built in four different plugins, none of which talked to each other - completely changed the project scope before I wrote a word of spec. The audit saved months of rework.

I check: plugin and theme versions, custom code quality, database structure, query performance, deprecated function usage, and anything that looks like it was built under deadline pressure and never cleaned up.

Automated scanners catch what's in their database. Manual review catches what nobody has written a rule for yet.

I check file access controls, database configuration exposure, XML-RPC status, whether user accounts can be enumerated, login protection, SSL configuration, and security headers at the server level. Then I look at what your existing plugins have access to and whether any of them are calling home.

Why it matters: On one audit, I found a freelancer had left a debug log in the web root with database credentials in plain text. The site had been live for 14 months. The client had no idea. That's not an edge case.

Is staging a subfolder of production? Is there version control? What's the deployment process - FTP drag and drop? That tells me everything about how the previous developer worked.

Are backups automated? Have they ever been tested? I'll ask for a restoration test during the audit. If nobody's ever run one, that's a risk that gets flagged immediately.

Hosting also matters. PHP version, server config, caching layer. These determine what's possible in the Develop phase without asking you to move infrastructure mid-project.

Core Web Vitals from CrUX field data - not just a Lighthouse run in a clean browser tab. Real user data, real conditions, real performance picture.

LCP, CLS, INP, TTFB. Database query count per page. I document everything before I touch anything. At the end of the engagement, the gains are measurable.

Note: Clients in government and financial services often need this baseline for internal reporting before work begins. Having it ready from day one saves a back-and-forth cycle mid-project.

What theme approach. What plugin stack. What requires custom development versus what can be solved with configuration. Why approach A instead of approach B - with the specific tradeoffs documented.

This document is the contract between what we agreed in a meeting and what I build. When a client's IT procurement committee asks why a particular technical decision was made three months later, the answer is already written down. Enterprise clients ask for this. I have it ready.

It also protects you. If a future developer inherits this project, they're not reverse-engineering decisions from code comments. The logic is there.

Staging mirrors production exactly. Same PHP version. Same server configuration. Same database structure. Same third-party API endpoints wherever possible.

On the Munich Re engagement, every deployment was reviewed against the staging environment by their internal IT team before anything touched production. That's the standard I bring to every project.

Staging also means the client can test. Not a screen share demo. Actual access, actual workflow testing, actual sign-off. If it doesn't pass in staging, it doesn't move to Deploy.

Database migration risks. Third-party API dependencies. Plugin conflicts flagged by the audit. WPML content structure edge cases. Each risk gets documented with a probability rating, an impact assessment, and a mitigation plan.

Great-West Life's Lifeco migration had a content structure risk I flagged in week two of the Design phase. That specific risk - how WPML relationship metadata would survive the export - would have caused partial data loss if it hadn't been caught before migration began. We caught it. The migration transferred cleanly.

Defined deliverables. Defined acceptance criteria. Nothing starts without agreement on what "done" looks like in writing.

Scope creep is the most common reason WordPress projects go sideways. And it's always preventable. A request that sounds small - "can we just add a custom field here?" - can cascade into a rebuilt data model if the scope wasn't drawn clearly.

For agency clients using white-label: the scope document is client-facing under your brand. I work to your brand. The client never sees my name unless you want them to.

Uptime monitoring with alerts configured before launch, not after the first outage. Server-side error logging active. Database query monitoring - slow queries flagged before they degrade user experience. Security event logging for failed login attempts, unauthorized file changes, and suspicious external access.

The monitoring dashboard is set up in the Deploy phase so that on day one post-launch, the baseline is already established. If traffic spikes, query times spike with it, or an error rate climbs after a plugin auto-update - you know immediately. Not when a user emails.

File access controls locked down at the server level. XML-RPC disabled if unused. REST API access restricted where appropriate. Login protection. Two-factor authentication for admin accounts. Security response headers - CSP, X-Frame-Options, HSTS - configured at the server level, not via plugin.

Wordfence or an equivalent tool is a layer in the stack, not the entire strategy. A firewall plugin that's not backed by server-level hardening is a speed bump. I build both.

Automated daily backups are table stakes. What most WordPress sites are missing is the restoration test.

I run a restoration test to a clean staging environment within the first month of the Defend phase. Then quarterly. Backup stored off-server - S3, Backblaze, or UpdraftVault - not on the same server as the site it's backing up. That one's obvious until you find a client whose "backup" was a folder on the same shared hosting account that went offline when the server failed.

Core Web Vitals tracked over time, not just at launch. Database query performance monitored. Caching layer verified after any plugin update or content volume increase. Image optimization checked after the content team starts uploading at scale.

Performance degrades gradually, then suddenly. A plugin auto-update, a new page template that loads three more scripts, a WooCommerce catalog that tripled in size - all of these show up in the monitoring before users start bouncing.