# WordPress rebuild project brief

Editable template by WP Forged, September 26, 2026.
Guide: https://wpforged.com/guides/wordpress-rebuild-project-brief/
Acceptance worksheet: https://wpforged.com/downloads/wordpress-rebuild-acceptance.csv

Copy this document and replace the prompts with your requirements. Mark unknowns instead of guessing. It can support a request for proposals; it is not a contract, legal advice, or a record of completed work. Remove irrelevant sections. Never include passwords, private keys, or confidential customer records.

## Project record

- Organisation:
- Current website:
- Brief owner and contact:
- Final scope/acceptance decision maker:
- Other reviewers and their responsibilities:
- Brief version and date:
- Desired decision date:
- Business timing constraints and their reasons:

## 1. Problem and desired outcome

- What is difficult or failing today?
- Which people and tasks are affected?
- What evidence do we have (URLs, dated measurements, feedback, examples)?
- What would a useful improvement look like?
- What is explicitly outside this project?
- Which concerns are confirmed and which are suspicions to investigate?

## 2. Architecture decision

- Has the team chosen to keep WordPress, go headless, or use another editor?
- If an architecture is required, why?
- Should providers also assess whether repairing the current site is sufficient?
- What unresolved question could change the decision?

## 3. Representative pages and content

For each important type, record an example URL and what must stay or change.

| Page/content type | Example URL | Content owner | Keep/change | Known exception |
| --- | --- | --- | --- | --- |
| | | | | |
| | | | | |

- Shared information used in several places:
- Archives, listings, languages, and downloadable files:
- Content needing cleanup, rewriting, permission, or replacement:
- Who will supply final copy, images, fonts, and other licensed assets?

## 4. Design and visitor tasks

- Design elements to preserve:
- Design work to commission:
- Mobile behaviours and priority visitor tasks:
- Accessibility requirements and any specialist reviewer:

| Visitor task | Current page | Current provider | Required outcome | Who receives/uses the result? |
| --- | --- | --- | --- | --- |
| | | | | |
| | | | | |

Include forms, bookings, donations, checkout, downloads, search, and logged-in tasks where relevant. Describe error and recovery requirements, not just successful submissions.

## 5. Editing and approval

- Who writes, reviews, publishes, and administers the content?
- Which changes must be possible without a developer?
- Which page-layout controls must editors retain?
- What may remain developer-managed?
- What should private preview show and who may access it?
- Are scheduling, unpublishing, deletion, revisions, or multiple languages required?
- How quickly must an approved update appear publicly?
- Who needs to know when publication fails?
- Representative task an editor will perform during acceptance:

## 6. Existing URLs, search, and measurement

- Known important URLs and downloads:
- Who can provide sitemaps, crawl records, search reports, and analytics access?
- Planned URL changes and who approves them:
- Metadata, structured data, languages, or archive requirements:
- Analytics properties and business events to preserve:
- Consent and privacy behaviours to preserve or review:
- Data unavailable to the provider and resulting uncertainty:

## 7. Scope and quote response requested

Ask each provider to respond with:

1. Proposed approach and reasons, including smaller repair options where relevant.
2. Deliverables tied to the requirements, with assumptions and exclusions.
3. Access, decisions, content, and work required from our team.
4. One-time charges and separately identified recurring charges.
5. Payment schedule, tax/currency basis, quote validity, and change-of-scope process.
6. Review stages, dependencies, and proposed delivery dates.
7. Acceptance checks and any investigation needed before a firm commitment.
8. Code/content/account ownership and handover deliverables.
9. Support hours, response expectations, coverage, and separately quoted work.

Use the companion cost worksheets to compare the same 12-month window. Unknown amounts should remain visibly unresolved.

## 8. Acceptance and decisions

Use wordpress-rebuild-acceptance.csv as a starting point. Add requirements specific to this site. Each should name an action, expected result, evidence, owner, and decision.

### Illustrative requirement only

- Need: An editor adds a workshop without a developer.
- Task: Enter title, date, image, description, and booking link; request review; then publish.
- Expected result: A reviewer can inspect the unpublished page privately. After publication, the correct page and intended listing show the workshop, and its booking link reaches the chosen provider.
- Evidence to request: Page and listing URLs, private-preview check, and a record of the observed publication result.
- Status: Example only; no implementation or test performed.

### Our acceptance rules

- Who can accept each requirement?
- Which failures block launch?
- Who may accept a limitation and where is that decision recorded?
- How will a failed check be corrected and retested?
- What evidence must accompany sign-off?
- Who decides whether a new request changes the scope?

## 9. Launch and recovery

- Launch decision maker:
- Person with domain/DNS/hosting/deployment authority:
- Required backups and confirmed owner:
- Traffic-switch steps and review window:
- Rollback trigger and authorised decision maker:
- How will content changes and submitted data be protected during rollback?
- Who checks the live site and handles unresolved issues?
- Agreed follow-up scope and period:

## 10. Ownership and ongoing care

- Repository and code ownership:
- Domain, hosting, CMS, and third-party account owners:
- Documentation and access the team receives:
- Who maintains WordPress, the public frontend, and integrations?
- Paid services and renewal responsibilities:
- Agreed support terms and exclusions:
- Handover to another provider if needed:

## Open questions and decision log

| Question/decision | Owner | Needed by | Answer or evidence | Status |
| --- | --- | --- | --- | --- |
| | | | | |
| | | | | |

The project is not accepted merely because this document has been filled in. Acceptance requires the agreed evidence and the named owner's decision.