In short: the time of a custom site depends mainly on the scope, the availability of content, the number of validations and the integrations to be made. A reliable date is built with a schedule, managers and acceptance criteria; it is not only deduced from the number of pages.
Two visually close projects can follow very different schedules. The first already has validated texts, a clear identity and a decision maker available. The second must clarify his offer, produce photographs, migrate data and obtain the agreement of several teams. Development is only part of the critical path.
The steps that really make up the schedule
scoping and collection
The project begins with objectives, audiences, journeys, available content and technical constraints. This phase fixes what will be delivered and what will remain outside the scope. It also reveals dependencies: access to the domain, advertising accounts, old hosting, API, legal notice or translations.
A short but incomplete scoping does not save time. Unmade decisions reappear during design or development, when they are more expensive to modify.
Architecture and content
The site structure organizes the topics; the contents specify what each page must allow us to understand or do. It is often necessary to prioritize offers, remove repetitions, prepare calls to action and identify available evidence.
Texts do not need to be perfect before the first visual work, but their messages and volume must be quite stable. Designing with false text and then replacing it with content three times longer leads to avoidable retakes.
Artistic direction and experience
The mock-ups translate the strategy into interface: navigation, rhythm, typography, images, components and responsive behaviors. Validations must focus on specific criteria, not just an instant preference.
An effective method brings together the feedback of all the people concerned. Contradictory comments sent separately extend the schedule and leave it to the service provider to arbitrate decisions that belong to the company.
Development and integrations
development turns mock-ups and rules into usable pages. Forms, payments, accounts, CRM connections or data migrations require access, test environments and error scenarios.
An external API can also impose its own schedule: account creation, validation, quota, incomplete documentation or intervention by another provider. These dependencies must be identified early.
Acceptance testing, corrections and online
The acceptance testing verifies paths, content, responsive, keyboard, metadata, performance, conversion tracking and error cases. For a redesign, it also covers redirects and the retention of useful URLs.
Finally, the online publication requires access to the domain, hosting and associated services. A launch window, a backup and a back-up solution reduce the risk without promising that no incidents will happen.
What most often prolongs a project
Delays rarely come from a single major obstacle. They usually come from a succession of small hold-ups: unapproved copy, a missing image, forgotten access details, a postponed decision or an unavailable decision-maker.
Common causes are:
-
a scope that changes after validation;
-
content produced too late;
-
several decision-makers without an arbitration rule;
-
an integration discovered during the project;
-
returns sent without priority;
-
incomplete source data;
-
an unplanned legal or business validation.
Adding a feature can seem fast when described in one sentence. However, it can modify the interface, data, permissions, tests and documentation. The good reflex is to measure its impact before inserting it into the current batch.
How to accelerate without sacrificing quality
Reducing the initial scope is often healthier than compressing all the steps. The project can be organized around a coherent version that covers priority journeys, then evolve after launch.
To protect the schedule:
-
appoint a person responsible for validations;
-
centralize content and feedback;
-
provide access from the beginning;
-
classify the functions as necessary, deferable and optional;
-
validate each phase before opening the next one;
-
set aside time for the acceptance testing and corrections.
Speeding up doesn't mean deleting tests. This means making fewer decisions in parallel and focusing the team on a clear launch goal.
Can we launch before everything is finished?
Yes, if the launched scope is self-contained, honest and genuinely usable. A first version may contain fewer pages or features, provided that navigation does not lead to dead ends and all essential information is present.
On the other hand, putting blank pages online, hiding untested functions or pushing back security is not a gradual launch. A reduced version must remain a complete version of the promise it displays.
For an application, this logic joins the frame of a web MVP. For a communication site, it often consists of focusing efforts on priority offers, evidence and contact.
What schedule to ask the provider?
The schedule must show the phases, deliverables, managers, dependencies and validation dates. A simple final date does not make it possible to know whether the project drifts or which decision is blocking it.
Also ask how new requests will be processed. They can replace a planned element, join a later phase or be the subject of a supplement. This rule protects both parties and maintains visibility on the maturity.
The budget and the deadline are linked: the more variants, content and integration the scope has, the more coordination it requires. Our guide on the cost of a website details these positions.
BlackStone Digital adapts the schedule to the reality of the project after scoping. To obtain a credible schedule, present the scope, available content and your deadline.
