Experienced US-Based WordPress Developer for Security-First Clean-Room Rebuild (Cloudflare)

UPWORK JOB TITLE Experienced US-Based WordPress Developer for Security-First Clean-Room Rebuild (Cloudflare) — Sole Developer / No Agencies / NDA + Independent Audit Required JOB DESCRIPTION (READ CAREFULLY — NON-NEGOTIABLES APPLY) I am seeking a senior, US-based WordPress developer to complete a security-first, clean-room rebuild of an existing website following a prior security incident. This is not a migration. No legacy code, databases, plugins, or configuration files will be reused or reviewed. All content is provided. The complexity of this project is not features — it is security discipline, verification, QA/QC ownership, cadence, and controlled execution. Restoring the site online matters, but rushing milestones, bypassing QA/QC, or shifting developer responsibilities onto the client is not acceptable. QA/QC, verification, documentation, and readiness for acceptance are part of what the developer is being paid for. This is a high-risk rebuild. The following are required and non-negotiable: 1. Clear milestone acceptance criteria 2. Live verification as needed to close milestones 3. Firm, predefined review cadence 4. Professional ownership of work (no client handholding) If you cannot comply with verification, as-needed screen-sharing, audits, documentation requirements, and firm acceptance rules — do not apply. I WILL PROVIDE 1. All written content 2. Images 3. Page references (visual only: screenshots / URLs — not code) CURRENT PROJECT STATUS (IMPORTANT CONTEXT) 1. Milestone 1 is complete and paid 2. Milestone 2 was near completion but not accepted 3. The new developer will pick up cleanly from the defined Milestone 2 scope 4. No prior Milestone #2 work is reused or assumed accepted BUDGET Fixed Price: $2,200 USD Structured strictly through Upwork escrow milestones Budget reflects Milestone 1 already completed and paid HOSTING / INFRASTRUCTURE (NON-NEGOTIABLE CONTROLS) • GoDaddy Managed WordPress • Cloudflare (DNS / security / performance) — client-owned and controlled • Developer may advise configuration needs but will not control Cloudflare or registrar settings SCOPE (CORE BUILD) 1. New clean WordPress install (latest stable) 2. Approximately 12–15 pages (content provided) 3. Approximately 12 forms 4. Homepage image rotation 5. OwnerRez integration using the official OwnerRez WordPress plugin and/or supported widgets • Availability, rates, rules, quotes, and booking flows • No custom payment gateways • Must follow OwnerRez’s recommended setup patterns 6. Responsive design 7. Build on non-public staging URL 8. Production deployment after approval OUT-OF-SCOPE (FUTURE, STAND-ALONE — NOT PART OF THIS ENGAGEMENT) A future FAQ Database is being developed as a separate, stand-alone initiative and is intentionally excluded from the scope of this rebuild. • Rebuild work focuses on containment, control, security discipline, and precise execution • FAQ Database work would involve a separate initial build, basic setup, structure, and one-time training • Ongoing FAQ updates would be handled internally or by another resource • Details, timing, and budget are not part of this contract • Completion of the rebuild does not imply future selection or commitment SECURITY STANDARDS (MUST FOLLOW) 1. Latest stable WordPress core 2. Plugins only from WordPress.org or official vendors (no nulled software) 3. Actively maintained plugins only (no deprecated or abandoned code) 4. No custom PHP unless explicitly approved in writing and documented 5. Cloudflare/WAF-aware build (rate-limiting for forms/login as appropriate) 6. Secure form handling required (spam controls, rate-limiting, least-privilege data handling) REQUIRED TECHNICAL SKILLSET • WordPress (clean installs only) • PHP (minimal, documented) • JavaScript (forms and interactions) • MySQL (WordPress schema familiarity) • Plugin configuration and hardening • Cloudflare-aware builds (DNS / proxy / WAF context) • Secure form handling and rate-limiting • OwnerRez WordPress plugin / widget integration experience DEVELOPMENT TOOLS & ACCOUNTABILITY Modern development tools (including AI-assisted tooling) may be used at the developer’s discretion. Requirements: • Developer remains fully accountable for all output • No blind copy/paste of generated code • Developer must understand, explain, and stand behind all work • All work must be reviewable live and traceable in GitHub • QA/QC is owned by the developer — not deferred to the client LIVE VERIFICATION (NON-NEGOTIABLE) • Live screen-shares are required as needed to close milestones • Screen-shares are used to verify implementation, test flows, and confirm GitHub commits • Refusal to participate in live verification = non-acceptance • Live verification will not be reframed as a “blocker” COMMUNICATION, REVIEW CADENCE & TIMELINE (NON-NEGOTIABLE) 1. Strict 5-week completion target for the remaining build and handoff (Milestones 2–5). Remediation identified through the independent security audit may extend beyond this window. Final payment is released only after audit-related updates are completed and verified. 2. Weekly or twice-weekly Zoom calls (typically scheduled in advance, with allowance for short-notice calls if a developer is unresponsive or a milestone is at risk). Calls may range from 30–60 minutes. 3. Asynchronous updates via Upwork messages are required between calls. 4. Fixed review cadence (no nudging, no pressure): • Development: Tuesday–Friday (ending 5pm MST) • Client review: Weekend • Client feedback by Sunday 11:59pm MST • Developer revisions: Monday–Tuesday (ending 3pm MST) • Milestone closure target: Tuesday 11:59pm MST 5. No nudging, pressure, or attempts to accelerate acceptance outside this cadence. Milestones are accepted only when work is complete, QA/QC’d, documented, and verified by the developer prior to submission. 6. Defensive, lecturing, or argumentative communication is not a fit. DOCUMENTATION REQUIREMENT (MANDATORY — PART OF EACH MILESTONE) Documentation is part of the milestone deliverable, not a post-acceptance task. Each milestone must include written documentation sufficient for a new senior developer to understand, verify, and continue the work without verbal explanation. Documentation must include, where applicable: • Configuration notes • Plugin purpose and key settings (including OwnerRez) • Form logic, routing, and validation • Security-related decisions • Deployment and rollback considerations Milestones without documentation will not be accepted. LICENSING / PLUGINS (NON-NEGOTIABLE) • Client purchases plugin licenses directly • Paid plugins must be identified early, justified, and confirmed legitimate • No reselling, bundling, or markup • Stripe account, products, prices, and payment links are client-owned MILESTONE STRUCTURE GOVERNANCE Milestone structure may be adjusted based on observed developer behavior, including: • Quality of deliverables • Adherence to cadence • Documentation clarity • Responsiveness and professionalism This improves efficiency — not accountability reduction or scope expansion. HARD CLEAN-ROOM BOUNDARY (NON-NEGOTIABLE) Do not request: • Old code • Old databases • Old plugins • Old configuration files (.htaccess, wp-config.php) Screenshots and URLs are acceptable. If you ask for “just a quick look” → hard stop. Developer must confirm in writing before work begins: “This site will be built from a clean WordPress install using current, actively maintained code and plugins, with no reused code or databases from the prior site.” OWNERSHIP & ACCESS • Client retains 100% ownership of all code and assets • IP transfers immediately upon milestone payment • No portfolio reuse without written permission • No retained access after handoff ACCESS CONTROL MODEL • Temporary WordPress admin access only • Limited, time-boxed SFTP/SSH if required • No GoDaddy, Cloudflare, or registrar access • Credentials rotated at handoff VERSION CONTROL • GitHub required (client-owned, private repository) • Developer access removed at handoff • No work accepted without commits SOLE DEVELOPER REQUIREMENT (CRITICAL) • US-based only • No agencies • No subcontracting • No assistants • No silent help You are fully accountable for all work. CONTRACT + NDA REQUIREMENT (BEFORE WORK BEGINS) 1. Scope and milestone acceptance criteria agreed before starting 2. NDA must be signed prior to access 3. Contract and milestones remain inside Upwork 4. External agreements may not override Upwork protections MALICIOUS CODE / BACKDOOR / PERSISTENCE (ZERO TOLERANCE) 1. Any intentional malicious code, credential exfiltration, hidden users, persistence mechanisms, or unauthorized callbacks constitute material breach 2. Contract terminated immediately for cause 3. No final payment released 4. Evidence may be preserved and reported to Upwork Trust & Safety 5. Unintentional vulnerabilities may be remediated within the defined window 6. Determinations based on independent audit findings INDEPENDENT SECURITY AUDIT (NON-NEGOTIABLE) • Independent WordPress security audit before final payment • Client covers audit cost • Final milestone released only after clearance • Audit conducted within 10–14 business days • Developer has 7 business days to remediate critical findings • Follow-up verification may be required TRAINING / HANDOFF (REQUIRED) 1. Step-by-step update training 2. Documentation for plugins, updates, backups, and key settings 3. Written confirmation that all developer access is removed and credentials rotated PAYMENT STRUCTURE Total Budget: $2,200 • Milestones 2–5: $300 each • Final milestone (post-audit): $1,000 Acceptance is based on outcomes, QA/QC, documentation, and verification — not hours worked. TO APPLY — ANSWER ALL QUESTIONS (REQUIRED) 1. Explain Cloudflare’s role with WordPress (DNS / proxy / WAF). 2. Describe your clean-room rebuild process after a security incident. 3. Confirm you will not request or reuse any old code or databases. 4. List exactly what access you require and confirm what you will not request. 5. Confirm you will participate in as-needed live screen-sharing to close milestones. 6. Confirm you are the sole developer performing the work (city/state required). 7. Describe your QA/QC process for multi-form builds and OwnerRez integration. 8. Describe how you implement OwnerRez using only official plugins and supported widgets, and confirm you have reviewed OwnerRez’s official integration guidance: 9. Confirm support for independent security audits and remediation timelines. 10. Confirm you will not pressure for early acceptance or accelerated releases. FINAL NOTE This project is about professional ownership, QA/QC discipline, and clean milestone closure. Senior developers will recognize this as standard. If you feel the need to push back on verification, cadence, documentation, or accountability — do not apply. Apply tot his job