A website timeline is a chain of decisions, not a row of design dates. Final copy has to be approved before you can check the final page. A client review is not final sign-off. Sign-off is not a public launch. Handover is another deliverable. When an input arrives late, update the dependent milestone rather than quietly compressing every check into the last afternoon.
This guide follows a fictional small-site project. The sequence and dates are illustrations, not a promised delivery duration or a TASKUL customer case. Your own scope, contract, team, access and technical risk may require more stages.
Agree what each milestone means
Before estimating dates, define the finish line. “The site is ready” might mean the designer has a review link, the client has approved the final content, the site is live, or the client has access and instructions to operate it. Those are not interchangeable.
A usable milestone names its owner, required input, output and exit check:
| Milestone | Owner and input | Evidence that it is complete |
|---|---|---|
| Brief and scope agreed | Client and designer; page list, content owner, required assets, review and revision process | Approved brief or proposal |
| Design direction approved | Designer shows the agreed design direction; client chooses it before full build | Direction and version approved |
| Final content supplied | Client; approved copy, images and usage permissions | Final files and a named content approver |
| Build and internal checks | Designer or build team; approved design and content | Key pages, links, forms and relevant devices checked for review |
| Near-final site review | Designer sends the checked site; client gives one decision or consolidated comments | Review notes tied to a version |
| Final approval | Named client approver; final review version | Written permission for the next stage |
| Launch | Authorised publisher; access, domain and release plan | Public pages checked after publication |
| Handover | Designer and client; access, files, instructions and unresolved items | Receipt of agreed materials and owner for follow-up |
You may combine or split stages in a real project, but keep their meanings distinct. The Australian Graphic Design Association's studio-management guidance advises including client review and revisions in project schedules. The Design Institute of Australia's guidance on briefs explains why defining the work early matters. Neither source supplies a universal number of days for your project.
Map the whole project before the final week
For the same fictional small site, a whole-project plan might be recorded as four phases. These are sequencing examples, not standard durations:
- Brief and scope: agree the page list, audience, content owner, approval owner, revision process, accessibility needs and what “launch” includes. The output is a brief both sides can point to.
- Structure and design: draft the page hierarchy and direction, review a representative page, resolve conflicting feedback and record approval of the design direction. This approval is for the direction, not for the finished site.
- Content and build: collect approved copy and licensed assets, build the agreed pages, check the content version, links, forms and relevant screen sizes internally, then send a near-final version for client review.
- Approval, launch and handover: apply agreed revisions, run final checks, obtain written release approval, publish, verify the live site and transfer the agreed materials and access.
Put an owner and an exit check against every phase. Estimate dates from the real page count, availability and review process; do not copy the five-day example below as the length of the whole project.
Work backwards from the requested launch
Suppose a client requests a Friday public launch. A draft homepage design is approved, but final copy has not arrived. One possible illustrative plan is:
- Monday: client delivers final approved copy and names who can approve the page.
- Tuesday: designer places the copy and checks layout, links and the mobile version.
- Wednesday: client reviews the near-final site and returns consolidated feedback.
- Thursday: designer applies the agreed changes, runs final checks and obtains written approval.
- Friday: an authorised person publishes, checks the live pages and starts the agreed handover.
This is a dependency example, not a five-day website-build promise. It assumes the site structure, design and access are already prepared and that each reviewer responds as agreed. If those conditions are false, the plan must change before anyone confirms Friday.
Work backwards by asking: What must be true immediately before launch? What must be true before final approval? Which decisions belong to the client, and what happens if they are late? Write those assumptions beside the date. A timeline without its assumptions can look precise while hiding the real risk.
The worked milestone file shows the owner, input, state and next action for this fictional project. The blank file can be adapted to your own agreement.
Show what two days of late copy actually changes
Now change one fact: the copy expected Monday arrives Wednesday. The designer may still prepare reusable components, check already approved pages and inventory the supplied images. The final homepage build, content QA and client approval depend on the approved text and cannot honestly be recorded as completed on Tuesday.
The original Wednesday client review is no longer possible on the same basis. First confirm whether Wednesday's copy is approved. If it is, the designer may be able to place and check it Thursday and offer a Friday review instead of the planned Friday launch. If the client reviews on Friday and returns one agreed revision on Monday, the designer could revise and run final checks on Tuesday, request written approval on Wednesday and launch on Thursday, subject to the people and checks actually being available. These dates are a worked replanning example, not an automatic new promise. If the copy is still a draft, even the Friday review needs a fresh estimate.
Keep the revised record factual:
- Original input: approved homepage copy expected Monday.
- Actual input: copy received Wednesday; approval status must be confirmed before the revised sequence is offered.
- Work completed independently: components, approved-page checks and asset inventory.
- Work still dependent on copy: final page build, content check, client review, corrections and sign-off.
- Decision required: whether Friday becomes a review slot, what moves, and who approves the new plan.
The Australian Government's contractor contract guidance explains why scope, milestones and variation processes should be stated clearly. If Friday is a contractual launch date, do not treat a status email as an automatic extension. Follow the agreement's process to change it.
Tell the client what can still happen
Send an update before the client sees the unchanged date and assumes the project is on track. A useful message separates facts, options and the decision you need:
The homepage copy arrived on Wednesday rather than the Monday date in the project plan. Please confirm it is the approved final version. I have finished the components and checks that did not depend on it. I still need to place and check the final text, send the page for your review and complete any agreed changes before publication. If the copy is approved and Thursday's checks are complete, I can offer Friday for the homepage review. After your feedback I will confirm the revision, approval and launch dates. Please confirm who can approve the final page and whether this change should follow the variation process in our agreement.
Do not send a bracketed or guessed date as if it were agreed. If the client needs to keep Friday, discuss the actual alternatives: a smaller agreed launch scope, additional resourcing if available, or a later date. Check the cost, quality and contractual consequences before accepting one. Leaving a required test or approval out without telling the client is not a plan.
Give reviews an owner and an exit condition
A calendar block called “client review” is incomplete. Say which version the client will see, who can approve it, how feedback should be combined, when it is due, and what counts as approval. If two reviewers give conflicting instructions, pause the affected item until the named decision owner resolves them. The feedback guide shows how to separate agreed edits from questions and additional requests.
Do not label the whole site “approved” because one page or one stakeholder received a link. Record approval against the deliverables listed in the brief. If an extra page or new section is requested during review, treat it as a proposed change until scope, content ownership, timing and any commercial terms have been agreed. The AGDA proposal template gives a useful model for making deliverables, revisions and additional work explicit.
Check the site before and after publication
The exact QA list depends on the build, but an agreed launch should include a deliberate check of the paths users need. At minimum, for each in-scope page, confirm the correct content version, working navigation and links, readable headings, images and text alternatives where appropriate, and the important mobile and desktop layouts. Test each form's successful and failed states without submitting real personal data into a test flow. Check the actual destination after launch, not only the preview.
The W3C's Easy Checks offers a starting point for reviewing accessibility, including page titles, headings and image alternatives. Those preliminary checks are not a substitute for a complete accessibility evaluation or a guarantee of compliance. If accessibility requirements are in the agreement, test against the agreed standard and record what was checked.
Keep a short release record: the approved version, approver, date and time zone, pages published, checks performed, known issues and owner of each follow-up. This is especially useful when the person publishing is not the person who designed the pages.
Handover is a milestone, not an afterthought
Agree what the client receives after publication. Depending on the job, that may include design files, content guidance, account or hosting ownership, a list of licences, a short editing walkthrough, backup or recovery information, and known maintenance items. Transfer access through an appropriate secure channel; do not place passwords in a public project sheet or ordinary status email.
Close the project only when both sides know which items are complete and who owns the remaining ones. If invoicing follows a milestone, use the terms in your agreement. For Australian invoicing requirements, refer to the Australian Government's invoicing guidance rather than copying someone else's tax wording.
The method works in a calendar and spreadsheet. TASKUL's English product page is available if you want to evaluate it; the free guide and files above work without an account. If this website competes with several other client jobs, use the multiple-project guide to revisit your real weekly capacity.
Questions to settle before confirming a launch
Can we launch while final copy is still being approved?
Only if the agreed scope explicitly allows the content that will go live and the authorised approver accepts it. Do not publish placeholder or unapproved claims as though they were final. Record which version is approved and what remains open.
Is a client review the same as sign-off?
No. A review invites a decision or changes. Sign-off is the agreed authority confirming the final version for the next stage. Name the decision owner and retain the evidence.
What if the client asks for a new feature during the final review?
Record the request, check its relationship to the agreed deliverables, and discuss the effect on work, date and terms before scheduling it. Do not silently add it to the launch-critical path or claim it is included without checking.
When should handover happen?
Define that in the brief. It can begin before launch with access and training, but the final handover record should reflect the live version, agreed files and known follow-up items. Treat it as a deliverable with an owner and completion check.
