Typical timing is scoped honestly
Quick fixes move faster than full rebuilds. Timings depend on approvals, content, access to existing systems, and whether domain or automation work is also in scope.
Process
Website project process, launch support, and handover without loose ends.
This page answers the “how” question in clearer search terms: how MichaelPC scopes a website project, what happens at each stage, and where approvals, launch support, and handover fit.
What keeps the process realistic
One delivery path works better when approvals, access, and launch blockers are surfaced early.
- Scope is clarified before build effort gets spent in the wrong place
- Access issues are surfaced before launch week turns into a scramble
- Automation and operational setup are only added where there is a defined business need
What helps timing stay honest
Delivery moves faster when the business facts, approvals, and source material are gathered in the order the work actually needs them.
- Business claims, pricing, and contact routes are checked before launch decisions harden
- Page structure, brand direction, and approval points stay tied to the real business goal
- Launch and handover are treated as part of the delivery path instead of an afterthought
What makes handover usable
The business should leave with a setup that can actually be operated after launch, not a pile of unresolved tasks.
- Admin routes, approval points, and launch authority are confirmed before the final switch happens
- Domain, email, redirect, and support boundaries are written down clearly enough for real day-to-day use
- Any agreed automation or chatbot work stays tied to a documented business purpose and fallback route
What the client usually needs to provide
Enough information to make the delivery accurate and safe.
Business facts
Core services, audience, contact details, pricing guidance, and anything legally important to the public-facing copy.
Access where it exists
Domain, DNS, hosting, email, current website, or platform access when the project involves existing systems.
Approvals on time
Reasonable feedback and sign-off so the website, policy text, and public claims are not delayed by avoidable uncertainty.
Timeline examples
Different job shapes move at different speeds.
Focused cleanup
Domain, DNS, redirect, or business email cleanup can often start quickly once access is available.
Website rebuild
A fuller rebuild normally depends on copy direction, approvals, and whether existing assets need to be rescued or replaced.
FAQ chatbot or automation assistant
The timing depends on how much approved source material exists, how much process logic needs to be programmed, and whether the automation touches sensitive information or internal systems.
Combined launch
Website, domains, email, and automation support can be handled in one project when the scope is clearer than separate fragmented suppliers would allow.
Contract boundary
The consultation, proposal, and approval steps are separate on purpose.
The website enquiry starts the conversation. Paid work starts only after a written proposal or statement of work is accepted and any agreed first payment is in place.
Read the terms Review proof outputs