The project objective is to bring the Halal Fest website go-live on 28/09/2026, complete hypercare, handover and project closure no later than 30/09/2026, ensuring stable operation before 01/10/2026.

The frontend and backend are developed in parallel on WordPress. The frontend builds reusable components, page sections and templates, combined with custom CSS, JavaScript or custom code for advanced features. The backend locks the data structure, API and business logic. The two sides integrate continuously by page group and feature.

Delivery principles

• Lock the structure first: ACF JSON, REST schema and seed data are committed to the repo before broad development.
• Parallel development: Frontend and backend run concurrently on the same local and staging environments, integrating by page group.
• Gated acceptance: each phase has specific outputs, approvers and completion criteria; UAT only begins after internal QA is complete.
• Content by batch: Client Marketing enters content in parallel with development as soon as each template is delivered on staging, not waiting until the end of the project.

Four items the PM must confirm this week

A roughly 10-week roadmap from kickoff to go-live. Phases are deliberately overlapped: frontend and backend start together after contract lock; content is entered by batch in parallel with development.

Each milestone is an acceptance gate with specific outputs and approvers. The two design gates (gold) are entry conditions for Phase 1 and Phase 2, not a separate design phase.

Three concepts are clearly distinguished at scope sign-off: a Page is what the user sees; a Template is a layout reused across pages; a Feature/module is an operational function. The number of pages does not equal the number of layouts; 9 template groups do not represent the entire feature scope.

Other supporting items: SEO, website security, application-level backup and cross-browser QA, accepted under the criteria in section 08.

The frontend and backend are developed in parallel on WordPress. The frontend builds reusable components, page sections and templates, combined with custom CSS, JavaScript or custom code for advanced features. The backend locks the data structure, API and business logic. The two sides integrate continuously by page group and feature.

Integration principles

• ACF JSON and REST schema are committed to the repo and versioned; no manual configuration on a single database only.
• Backend provides VN/EN seed data early so the frontend can build and test templates with real data.
• Items marked with shared ownership (FE + BE) are only accepted when both sides confirm integration.
• Integration results are tested on staging by page group, not deferred to the end of the project.

Content responsibility

The Vendor builds the framework, templates and features. Client Marketing enters, edits and approves content, by batch in parallel with development as soon as each template is delivered on staging.

Primary owner: Client Marketing. Support: PM, Frontend and Backend.

Team Central support scope

Changes to content, interface, features and application-level operation of the website are handled by the project team working directly with the Vendor.

A table assigning the primary owner and support party for each operational, license and infrastructure item, used as a basis when requests arise during implementation and after launch.

Separately charged items outside the basic website scope

The items below are quoted and charged separately and are not part of the basic website build scope. The contract should state these clearly to avoid confusion over scope and cost.

Client UAT only begins after internal QA is complete and the website is confirmed ready for client testing.

UAT sequence

Acceptance conditions

• Functionality: every feature in the scope matrix meets its acceptance criteria; shared-owner items are confirmed by both sides for integration.
• Quality: no blocker or critical bugs remain; test evidence is stored in the test report.
• Multilingual: no language mixing; menu, slug, taxonomy and forms fully translated VN/EN.
• Email: SPF/DKIM confirmed; test delivery evidenced by successful send and receive.
• Analytics: GTM preview and GA4 DebugView confirm correct events and parameters.
• Security and backup: login protection and CAPTCHA working; application-level backup has a restore-test result.

Performance criteria

Launch ownership

Launch preparation (23-27/09)

• Content freeze in effect; only fix display errors, images, broken links, formatting or translation.
• Production content check, hosting readiness and backup/restore rehearsal.
• Confirm DNS/SSL, production access, rollback plan and launch checklist.

Go-live (28/09)

• Vendor performs production deployment and smoke test per checklist.
• PM confirms the website works and notifies the relevant parties.

Hypercare and handover (29-30/09)

• Dev on-call, logs incidents and handles hotfixes.
• Hand over source code, accounts, user manual and operation documents.
• CMS usage training for Client Marketing (2-4h) if not completed during UAT.
• Post-handover warranty is performed within the contract scope.
• Confirm project closure no later than 30/09/2026.

The points below are not yet locked in the source document and require the PM to confirm in writing, prioritized before the M1 milestone (31/07).

Change management principles

• After full design freeze (07/08), changes that add templates, data structure or new features are change requests and require re-assessment of timeline impact.
• After content freeze (22/09), no new pages or major layout changes.
• Every scope adjustment is recorded in writing and updated in the scope matrix in section 05.