If you are planning a site and want the handoffs defined before work starts, tell ARCHV about your project. If you are already in a delayed project, use the checklist below with your current provider first.
A website schedule can move for many reasons. Approved copy may be late. A third-party platform may be harder to integrate than expected. The design may require a decision nobody has made. But a useful update should tell you which reason applies and what happens next. “We are working on it” is not enough to plan a launch.
Put the current position in writing
Ask for one written status that covers five things:
- Completed and reviewable work. Name the pages, designs, functions, and content already finished. Ask for a link or file you can inspect, rather than a percentage complete.
- Remaining deliverables. Compare the work left with the signed scope, not the latest verbal promise.
- Blockers and owners. Is the next action with the agency, your team, a vendor, or an approver? Give each blocker a named owner.
- A revised sequence. Ask for the next review date, the next decision, testing, and launch. A single new launch date without intermediate milestones is hard to verify.
- Changes to price or scope. If a platform, feature, or page list changed, ask what was reapproved and what it costs.
Send the request through the channel named in your agreement and keep the response with the project record. A calm, specific request gives a good provider a fair chance to reset the work and makes a genuine dispute easier to understand.
Separate a delay from a scope disagreement
Review your own obligations as carefully as the provider's. Did the quote say you would supply final copy, product data, images, or feedback by a date? Were there multiple reviewers sending conflicting instructions? If those inputs are late, a revised timeline can be reasonable.
If the provider says a newly discovered requirement changes the schedule, ask them to identify the original assumption and the new requirement. A payment integration, data migration, or new page layout may genuinely be extra work. The decision should be explicit: approve a revised scope, reduce the work, or defer the feature.
Ask for a recovery plan, then test the next milestone
A recovery plan should identify a small, inspectable next deliverable. For example: “By Friday, send the mobile and desktop service-page build with a working inquiry form on staging.” It should also explain what happens if the blocker remains unresolved. This gives both sides a way to tell whether the project is moving again.
If the next commitment is missed without a clear explanation, check the contract's escalation, termination, refund, and handover clauses. Do not stop payments or transfer accounts based on a blog post; those steps depend on your agreement and the work already delivered. Preserve copies of the proposal, approvals, invoices, status messages, and any accessible files.
Prevent the same uncertainty in a new project
Before you sign the next website proposal, ask it to name the decision-maker, review stages, content owner, update route, and how a delayed dependency changes the schedule. ARCHV's website process describes staged approval and written scope changes. A specific project schedule is set after the brief, content, platform, and approval path are reviewed; it is not a universal turnaround promise.
If you want a new brief checked for missing milestones and responsibilities, contact ARCHV or use the website quote review.
A public client review describing shifting dates and vague updates during a platform change is one person's reported experience, not a finding about that agency's other projects. Its useful lesson is to ask for a written cause, next deliverable, and decision owner whenever the plan changes.