TL;DR
The short answer
At OROS, a landing page usually takes 7–14 days and a standard website 14–20 days. See what can speed up or delay the schedule.
Use the detail below to choose the right next step.
| Topic | how long does it take to have a website built |
|---|---|
| Region | Kerkrade · Zuid-Limburg · Netherlands & Belgium |
| Current status | Reviewed and kept up to date: 12 September 2026 |
| Next step | Scope first, then a clear price direction |
At OROS, I usually allow 7 to 14 days for a landing page. A standard business website normally takes 14 to 20 days. A more complex website can take anything from 14 days to about a month.
These are OROS timelines, not market averages. I can give a firm estimate once I understand the scope, the number of distinct page types, the state of the content and the functions the website needs.
There is another distinction that is easy to miss. The time I spend building the website is not always the same as the total project duration. My work can stay on schedule while the launch still moves because photographs, copy, feedback or approval have not arrived.
A useful timeline therefore covers more than the developer’s working time. It also states what both sides need to supply or approve and when.
Typical OROS timelines
| Type of project | Usual OROS timeline | What it normally includes |
|---|---|---|
| Landing page | 7–14 days | One main page for a service, advertising campaign or specific offer |
| Standard business website | 14–20 days | Several recurring page types with a clear structure |
| More complex website | From 14 days to one month | More unique layouts, unusual content, integrations or added functionality |
These ranges are a starting point, not a promise for every project. A small website with no prepared content can take longer than a larger project where all the important decisions have already been made.
The page count does not tell the whole story
A twenty-page website can be fairly straightforward if every page follows the same layout. Once the first page type has been designed and built, the remaining content can follow the same structure. Each page still takes time, but it does not need to be designed from scratch.
Five pages with five different structures are another kind of project. I need to decide what information comes first, how each page works on a phone and what the visitor should do next. In practice, those are five separate page designs.
That is why I look first at the number of unique page types. A service page, catalogue, product page, case study and calculator can require more decisions than dozens of similar articles.
Some work barely changes with the size of the website. Even for one landing page, I need to understand the business, review competitors, clarify the offer and agree the direction with the client.
What happens before development begins?
From the outside, a website project can look like a design followed by a technical build. A large part of the work happens before that stage.
I first need to know who the website is for, what that person should understand immediately and what action they should take. Then we define the structure and collect or create the copy and images. When an old website is being replaced, we also decide which content stays and what happens to the existing page addresses.
The build itself may move quickly. But the plan changes when the company’s offer changes halfway through the project, an extra language is added or a new type of page appears.
Changes are sometimes the right decision. They still add time as well as cost.
What usually delays a website launch?
In my projects, delays most often happen while information or approval is pending. Work may have to stop while I wait for:
- copy, photographs, a logo or details about the services;
- one final response to the design rather than separate comments from several people;
- approval of prices, conditions or other factual statements;
- feedback on a completed stage;
- payment for the next phase when that is part of the agreement.
I normally start almost immediately after receiving the deposit. The sooner the information is available and decisions are made, the easier it is to keep the original schedule.
Unexpected issues can occur on my side too. I leave some room in the plan for them. Even so, an honest launch date still depends on both parties doing their part.
A requested date is not yet an agreed deadline
“We need to launch on Monday” tells me the work is urgent. It does not create a confirmed deadline. Before I reserve time, we need to agree the assignment, scope and price. The deposit must be paid, and I need the information and access required to begin.
An introductory conversation or request for a quote does not reserve a slot. Until the project is confirmed, I do not know whether the client has chosen OROS, how much capacity the work needs or when it will actually be ready to start.
This is particularly visible in advertising projects, but the same rule applies to websites. In one anonymised example, a company wanted its advertising to start on Monday. By Friday, the engagement was not confirmed, the deposit had not been paid, access to the advertising account was missing and no budget had been added. The audience and target area had not been decided either. The website also needed changes that could affect how well the campaign worked.
The project was not running late. It had not reached the point where work could begin.
The same thing happens in web development. An owner receives an initial estimate of at least two weeks, disappears for several weeks and then returns with a larger scope and the same launch date. A provisional estimate cannot hold time in the diary indefinitely. The scope and available dates have changed, so the timeline needs to be confirmed again.
I am responsible for completing the agreed work and reporting risks on my side. The client supplies decisions, materials, access, feedback and payments at the agreed points. This is not about assigning blame. The project depends on both parties.
Content affects the timeline more than many clients expect
Empty blocks are quick to build. A business website still needs a clear offer, accurate information and suitable images. “We will send the copy later” can leave an almost completed website without a launch date.
The fastest projects start with the client’s copy, photographs, prices and business information already available. The material does not need to be publication-ready. Rough information and confirmed facts are enough for me to see what can be used and what is missing.
If there is no content yet, I can help with the structure, writing and visual direction. I can also generate some of the images. This only saves time when I have enough information and room to propose decisions without asking for separate approval on every sentence.
The client still checks the facts and approves the final version. If the company wants to produce all content internally, that work needs to be included in the schedule.
Integrations and added functionality
A simple contact form rarely changes the scale of a project. A CRM integration, online payment or calculator needs more preparation.
We need to define which data is sent, what happens after a form is submitted, who receives the notification and what should happen when something fails. Payments need successful and unsuccessful scenarios to be checked. A calculator needs agreed calculation rules before its presentation can be designed.
These features do not necessarily add months. They just cannot be estimated as one more button on a page. The earlier their behaviour is described and approved, the more reliable the timeline becomes.
Can a website be built urgently?
Sometimes. Under the right conditions, I can shorten the usual timeline by around 30 to 40 per cent.
An urgent project works when the information is immediately available or the client gives me enough freedom to finish the copy and images. One person needs to make quick decisions, and the scope must stay stable while I work.
Urgent work normally costs more because the project takes priority in the diary. There is also less time for alternative versions, several relaxed editing rounds, visual refinement and repeat checks. The result may be a little less polished than it would be on a normal schedule.
That does not mean an urgent website has to be poor. We agree the smallest version that can be launched properly on the required date. Less important pages or improvements can follow in a second phase.
Fast, inexpensive, highly customised and open to several rounds of approval cannot all be priorities at once. The client has to decide what matters most.
Who should communicate with the web developer?
One contact person helps only when that person understands the business, can obtain information from colleagues and has authority to make agreed decisions. If final approval stays with the owner, the contact person needs a quick way to reach them.
Even an experienced head of sales may not know which product has priority, which budget has been approved or which claims may be published. If the developer is told to decide those points alone, the project becomes risky. I can study the market and recommend an approach, but I cannot reliably invent a company’s internal priorities.
In one anonymised project, an owner appointed an employee as the contact person without giving them all the information or authority they needed. The employee had to go back to the owner for every important answer. The owner believed the project had already been delegated. There was plenty of communication but very little decision-making.
For a microbusiness, it is often practical for the owner to explain the services, customers and goals at the start. Routine questions can be delegated afterwards.
A small or medium-sized company can appoint a coordinator to gather materials and combine feedback. Agree in advance what that person may approve and when the owner or department manager must be involved.
Larger organisations also benefit from one main contact. Marketing, sales, IT and legal specialists can review their areas, but the coordinator should pass one final answer to the developer.
The owner does not need to attend every conversation. Their input matters when the purpose and positioning are set, when budget or scope changes and when a decision affects the business itself.
How to help the project finish on time
Before work starts, agree who combines feedback, who approves the structure and copy, who supplies technical or legal information and who decides when colleagues disagree.
Collect the basic facts too: services, prices, service area, contact details, logo, photographs and required company information. If something is missing, say so before the start. Its preparation can then be included in the schedule.
Explain the reason behind the deadline. A new location, advertising campaign or trade show changes the priorities. When I know about it early, we can build the smallest useful first version and move non-essential sections to a later phase.
When does the project clock start?
I normally start almost immediately after the deposit is paid. The clock does not start at the first conversation about an idea. The assignment, scope and price need to be confirmed first. The invoice details, key materials and essential access also need to be available. The exact list depends on the project.
That is why a proposal should not contain only an end date. It should also set out when content is supplied, the structure is approved, feedback is due and project phases are paid.
If essential information arrives five days late, the launch does not always move by exactly five days. Other work may have been placed in the newly available space. After a pause, I confirm the next realistic date again.
The schedule needs to fit the assignment
At OROS, a landing page usually takes 7 to 14 days. I normally plan 14 to 20 days for a standard website. A more complex site can take from 14 days to about a month. In some cases, the work can move around 30 to 40 per cent faster when the material is ready or I have enough freedom to complete the content.
The most useful estimate does not begin with a row in a table. I look at the unique page types, the available content, the people making decisions and the features that must work at launch.
Do you have a fixed date for your website? Describe the project in writing. I will determine which first version is realistic, how much time OROS needs and what your organisation must provide to keep that schedule.
If you are comparing time and budget together, read what a website costs in the Netherlands in 2026 and use the website calculator for an initial indication.
FAQ
How long does a landing page take?
At OROS, a landing page usually takes 7 to 14 days. The exact schedule depends on the available content, the number of unique sections and the speed of feedback.
How long does a standard business website take?
OROS normally plans 14 to 20 days for a standard business website. A more complex website can take from 14 days to about a month.
Can OROS build a website urgently?
Sometimes the normal timeline can be shortened by around 30 to 40 per cent. This is possible when the information is immediately available or OROS has enough freedom to complete the copy and images. An urgent project normally costs more and leaves less room for alternative versions and revision rounds.
Why do website projects get delayed?
Within OROS projects, common causes include late content, time spent waiting for approval, delayed feedback, changes in scope and postponed payments for agreed phases.
Does a website with many pages always take longer?
Not always. Twenty pages based on one template can require less design work than five pages with different structures. The number of distinct page types often matters more than the total page count.
Does an enquiry or introductory call reserve time?
No. A slot becomes firm after the assignment, scope and price are confirmed, the agreed deposit is paid and the required information and access are available.
What happens if information or feedback arrives late?
The project may have to pause and the delivery date will be reviewed. The shift is not always equal to the exact number of delayed days because other work may have been scheduled in the meantime.
Who should be the contact person for a website project?
Choose someone who understands the business and the purpose of the website, can obtain answers from colleagues and has clear decision-making authority. If final approval stays with the owner or directors, agree when they will be available.
A useful next step
Discuss your website schedule
Describe your project briefly in writing. Daniel will review the scope, available information and target date before discussing a realistic schedule.
Discuss your project →
