When a company asks how long it takes to build a website, the answer depends on much more than the number of pages. For a straightforward corporate website, the amount of content may be the main factor. For an online store with a large product range, customer-specific pricing or an ERP connection, the timeline will be shaped mainly by data, integrations and internal decision-making.
This is why giving a fixed deadline before understanding the project often creates a false sense of certainty. A reliable timeline should be based on scope, dependencies and the approval process—not on a generic estimate applied to every website.
How long does a custom website take?
A custom website timeline can be estimated properly once four areas have been defined: what the platform needs to do, what information it must contain, which systems it needs to connect to and who will approve each phase.
Adapting a standard structure is not the same as creating a tailored content architecture, designing several page or product templates, developing specific features and synchronising the website with internal systems. Custom development does not necessarily mean building everything from scratch. It means deciding which requirements can be handled with reliable components and which need a bespoke solution.
It is also important to distinguish between design and development. Design defines the structure, navigation, information hierarchy and interface behaviour. Development turns those decisions into a functional, secure and connected platform. If both phases move forward without a shared definition, late changes are likely to affect the schedule.
What causes the biggest delays in a website project?
Content that is not ready
Copy, images and commercial information cannot always be left until the end. They affect page length, visual hierarchy, filters, SEO and even some of the website’s functionality.
In a distribution company, for example, it is necessary to decide how product families are organised, which attributes will be displayed, what documentation can be downloaded and what criteria a customer will use to find a reference. Before deciding whether a digital catalogue, a downloadable document or a combination of both is appropriate, it is useful to assess what type of product catalogue the company needs.
A large catalogue or one with irregular data
Importing products is not just about transferring a spreadsheet. It is common to find duplicate categories, incomplete descriptions, different units, unmatched images or references that do not follow a uniform criterion.
Before loading the catalogue, a data structure must be established and the correct source determined. If this work is not identified at the beginning, it can block development or force repeated imports and revisions.
Approvals without owners or dates
A project can stall even if design and programming are progressing correctly. This happens when it is unclear who approves the structure, who reviews the texts or which people need to validate the commercial terms.
Approvals work best when each phase has an owner, a date and specific criteria. It is also advisable to centralise comments. Receiving contradictory instructions through different channels generates unforeseen iterations.
Scope changes during development
Adding a language, a private area, customer-specific pricing or a new logistics flow may be reasonable, but it is not a minor adjustment. Each new requirement can affect the design, the database, permissions, testing and integration with other systems.
This does not mean the project has to be frozen. It means that changes must be evaluated and prioritised: incorporate them into the first version, replace another feature or schedule them for a later phase.
If content, purchase journeys and functionalities need to be organised before programming, a user-centred web design process focused on the actual business structure allows for defining a clear foundation and reducing late changes.
How long does an online store with ERP take?
An online store with ERP requires more definition than an e-commerce managed independently. The question is not just whether the two systems can connect, but what information needs to flow, in which direction and how often.
Before calculating the timeline, questions like these need to be answered:
- Where are products created and updated?
- Which system controls stock, prices and rates?
- Should the website send orders to the ERP automatically?
- Are there B2B customers with different commercial terms?
- How are incidents managed if a synchronisation fails?
- Does the ERP have an API or is another exchange mechanism needed?
An API is a way for two applications to exchange information in a structured manner. The fact that the ERP has one does not, by itself, mean that integration is immediate: it is necessary to check what data it offers, how it identifies each record and what limitations it has.
Tests with real data, error logs and mechanisms to prevent duplicates must also be planned. This part is often invisible to the buyer, but it is what ensures the store does not generate more administrative work than it saves. Web development with integrations and custom functionalities must consider these flows from the initial architecture.
How can a realistic timeline be set before contracting?
A good quote should not only indicate a final date. It should explain the project phases, what needs to be delivered in each one and on whom progress depends.
- Functional definition: objectives, audiences, content types, functionalities and systems involved.
- Architecture and design: navigation structure, prototypes, interface and behaviour on different devices.
- Development: construction of templates, functionalities, content management and integrations.
- Loading or import: incorporation of the catalogue, texts, images, documents and metadata.
- Testing and publication: functional review, devices, performance, forms, purchase, analytics and SEO.
It should also make clear what is out of scope, how many rounds of changes have been planned and what happens if an approval or content delivery is delayed. This transparency helps compare providers beyond price or a promise of speed.
If the new platform replaces an existing website, the timeline must include URL inventory, redirects, metadata review and post-launch checks. The guide on how to plan a website migration without losing ranking or contacts explains why publishing is not simply about swapping one website for another.
Which decisions help meet the timeline?
The most effective way to shorten timelines is not to start programming sooner, but to reduce uncertainties beforehand. These decisions usually facilitate the project:
- Designating a person responsible for coordination and approval.
- Preparing a representative sample of the catalogue before designing the product pages.
- Identifying the ERP, logistics and content managers from the outset.
- Separating essential functionalities from those that can come in a later phase.
- Approving the structure and prototypes before entering development.
- Reserving time for real purchase, synchronisation and internal management tests.
For a store or distributor in Vallès or Barcelona, the realistic timeline is not necessarily the shortest. It is the one that considers the catalogue, commercial rules, integrations and decision-making time for all parties. A well-planned project prevents the website from being published quickly but then requiring data duplication, process correction or functionality reconstruction.
The useful question, therefore, is not just how long an online store takes, but whether the timeline covers everything needed for it to function stably from day one and evolve without rebuilding the foundation.
We like to talk about these topics before they become a closed project. Tell us about your case.