Timing starts with an agreed scope
A focused information page and a custom ordering system are different projects. The number of pages matters, but so do content readiness, integrations, approval decisions and the work needed after launch. A useful schedule reflects those requirements rather than one universal promise.
Direction and content come before a finished build
The first stage clarifies the offer, customer journey and needed structure. Real business details, prices and approved assets must then be collected or prepared. If the business is still deciding what it sells or how orders are handled, that decision work needs room in the schedule.
Build and review need clear responsibilities
The agreed pages and functionality are built, then reviewed within the scoped revision rounds. Consolidated feedback helps the designer understand what should change. New services, extra pages or a different ordering model can change the scope and timing.
Testing is part of launch preparation
Mobile layouts, links, contact paths, draft or submission states and important integrations need checking. A redesign or migration may also need redirects and domain or email dependencies reviewed. These checks protect the useful business journey rather than merely polish the appearance.
Ask for a date tied to real dependencies
Before paying, ask what must be supplied, who will approve the work and what is included in the launch. Confirm the delivery window once those responsibilities are understood. Urgency is useful context, but it should not hide missing content or unconfirmed functionality.
| Stage | What happens | Common dependency |
|---|---|---|
| Direction | Offer, structure and customer route | Business decisions |
| Content | Words, images and factual review | Owner-approved material |
| Build & review | Pages, features and scoped revisions | Consolidated feedback |
| Launch | Final checks and agreed switch | Access and sign-off |