The question about timing comes up in almost every first conversation, usually right after the question about price. It is harder to answer, because the answer depends less on the build than on the input. A modest company website is technically assembled in a few days; getting it live still routinely takes six to ten weeks. That gap almost never opens up at the keyboard. It opens up while waiting for photos, for sign-off and for access credentials. This article lays out the schedule: seven phases with realistic time frames, clear ownership, and a note on what typically blocks each one. Plus the three bottlenecks that explain nearly every delay in practice, a go-live window that does not cost anyone their evening, and seasonal planning that keeps the launch out of the busiest week of the year.
Why a website project rarely stalls on the build
Anyone drafting a schedule thinks in working days first: how long does it take to assemble pages, place copy, set up forms? That calculation is not wrong, it is merely incomplete. What matters is not working time but elapsed time — the span from the first conversation to a website people can reach. In a typical project the two differ by a factor of two to three: roughly fifteen to twenty actual working days spread across six to ten calendar weeks (project experience). The difference is waiting time, and waiting time almost always has the same cause: a contribution from the business is missing, or a decision is.
That is a description, not an accusation. A company website has long been standard in Germany: 94 percent (Bitkom, Digitalisation of the Skilled Trades) of trade businesses use one to be visible online, and 88 percent (Bitkom, Digitalisation of the Skilled Trades) add entries in online directories. At the same time 62 percent (Bitkom, Digitalisation of the Skilled Trades) see a concrete need to act on digitalisation, and 75 percent (Bitkom, Digitalisation of the Skilled Trades) struggle with a shortage of skilled staff. The same report explicitly names a lack of time, high costs and uncertainty around new technology as barriers (Bitkom, Digitalisation of the Skilled Trades); it is based on telephone interviews with 504 (Bitkom, Digitalisation of the Skilled Trades) trade businesses. People who are already short of time do not produce copy and photos on the side in the evening. A schedule that fails to account for this is fiction from day one.
The second cause is external pressure. 85 percent (Bitkom, Digitalisation of the Skilled Trades) of businesses observe a clear customer expectation of constant availability, and 89 percent (Bitkom, Digitalisation of the Skilled Trades) find that individual offers are expected. That is exactly why the new website is supposed to go live "as soon as possible" — and exactly why deadlines emerge that nobody can meet. Whether the investment pays off at all and how to tell is covered in the article on when a new website pays off. This one deals with the question that follows: once the decision is made, how long does it take?
Scope: schedule, not redirect engineering
The seven phases at a glance
Every website project breaks down into seven phases. They do not run neatly one after another; they overlap — copy is already being written while the structure settles, and final corrections run while testing is under way. The order is still binding, because each phase supplies a precondition for the next. Skipping phase three and pushing on to phase six only moves the problem to the point where it is most expensive: just before go-live.
Seven phases, seven time frames
-
Preparation and briefing — 3 to 5 days
The business clarifies what the site is meant to achieve: enquiries, appointment requests, applications, or explaining an offer that needs consultation. Add services, audiences, catchment area, existing material and the name of the person who signs off at the end. Without that name, phase two starts with a built-in defect.
-
Structure and first draft — 5 to 10 days
Site structure, navigation, a rough build of every page, first visual direction. The result is a draft you can walk through with placeholders, rather than a slideshow of design mockups. This phase sits almost entirely on the build side and is therefore easy to plan.
-
Copy and photos — 10 to 20 days
The real bottleneck. Copy has to come from the business or at least be checked for accuracy, and photos have to be taken or legally cleared. This phase derails schedules more often than all the others combined.
-
Legal pages, consent and accessibility — 5 to 10 days
Imprint and privacy notice matching the actual business, a cookie banner only where one is genuinely needed, plus contrast, labels, alternative texts and operability. Runs in parallel with phase three once the structure is settled.
-
Testing on mobile and keyboard — 3 to 7 days
Every page on a real phone, every function once using the keyboard alone. Submit the form, check the confirmation, tap the phone number, proofread the map and opening hours. The test is short — the corrections that follow are not always.
-
Domain move and go-live — 1 to 3 days
The switch itself is the shortest step and the least forgiving. Run-up: lower the TTL, verify access, secure email forwarding, choose the slot deliberately. Go-live takes minutes; propagation across the network takes hours.
-
Follow-up with fixes and a first review — 10 to 14 days
Two weeks of observation: broken addresses, form submissions, the first search queries, feedback from the team. Then a short review of what is actually being opened — and what should be cut or added.
In total that gives a frame of roughly six to ten weeks for a modest company website of eight to fifteen pages (project experience). Which pages belong there and which can be skipped is covered in the article on the pages a business website needs. Larger undertakings — several locations, several languages, an extensive service catalogue — mainly push phases two to four back, not go-live itself.
Who supplies what — and what blocks it
A schedule without ownership is a wish list. It pays to reduce every phase to three questions: what comes from the business, what happens on the build side, and what does progress hang on when things stall? The overview below is deliberately plain — it does not replace project planning, but it answers the question of whose turn it is at the next status call.
| Phase | From the business | Typical blocker | Time frame |
|---|---|---|---|
| Preparation and briefing | Goals, services, audience, catchment area, a named decision-maker | Nobody owns it; the briefing is cut short with "that's fine" | 3 to 5 days |
| Structure and first draft | Feedback on the site structure within two to three days | Structure is torn up again after the copy phase | 5 to 10 days |
| Copy and photos | Subject matter, price statements, references, imagery with cleared rights | Photos are missing; copy sits with three people at once | 10 to 20 days |
| Legal pages, consent, accessibility | Legal name, register data, tools in use, the person responsible for data protection | Details are copied from an old site and no longer accurate | 5 to 10 days |
| Testing on mobile and keyboard | Two or three people who genuinely test for an hour | Testing happens only on the office desktop, never on a phone | 3 to 7 days |
| Domain move and go-live | Access to domain administration, auth code, a list of mailboxes | Credentials sit with the previous provider and nobody asked | 1 to 3 days |
| Follow-up and review | Feedback from daily use, additions, corrections | After go-live nobody looks at it for two months | 10 to 14 days |
Note the third column: five of the seven blockers are organisational, not technical. That matches what happens in practice — the build is waiting, the business is not being held up. Going through this overview together before the start and entering one name and one date per row shortens elapsed time noticeably more than any speed-up on the build side. What such a sequence looks like in practice is shown step by step in how a website project runs.
The single most effective measure
The three classic bottlenecks
Delays look random case by case; in aggregate they are not. Across many projects, nearly all of them trace back to three causes. They show up in varying order, but they show up — and all three can be defused before the project starts, once you know them.
Missing or weak photos
The most common reason a finished website sits in draft for three weeks. No shots of the actual business, no rights to the existing material, no date booked for new ones.
Sign-off without an owner
Four opinions, nobody responsible. Every additional review round costs days without measurably improving the content.
Access obtained too late
Domain administration, DNS settings and, for a registrar transfer, the auth code. Sorting this out in phase six burns days at the point with no slack.
Bottleneck one: there are no usable photos
Photos are where most schedules tip over. The pattern usually runs the same way: at the briefing, images are said to be "plentiful". During the copy phase it turns out they are phone shots of building sites against the light, a group picture from the 2019 Christmas party, and a handful of images whose origin nobody can reconstruct. Then the real work starts: planning new shots, finding a date when the premises look presentable and the team is on site, and, if need be, waiting for better weather. Two to three weeks is realistic for that, and none of it appears in a schedule drawn up before the briefing.
The second half of the problem is legal. Imagery from an old website cannot automatically be reused if the licence was tied to the previous service provider. Photos of employees need consent, which does not arrive bundled with the employment contract. Third-party premises, client sites and identifiable people in the background each have their own rules. Which subjects carry a site and what to watch legally is described in detail in the article on photos and image rights on your website. For the schedule, one consequence is enough: the photo question belongs in week one, not week five.
- Book the date for new photography during the briefing, not later — the calendar is usually the constraint, not the camera
- Draw up a shot list in advance: team, exterior, work in progress, two or three finished results, vehicle or workshop
- Obtain consent from the people shown before the images go onto the website
- Clarify the origin and licence of every legacy image; when in doubt, drop it rather than hope
- Book a fallback date for outdoor shots — rain is a planning factor, not an exception
- Until the new images arrive, keep working with placeholders instead of pausing the copy phase
Bottleneck two: sign-off without a named decision-maker
The second bottleneck is less visible and works more slowly. It appears when sign-off goes to a group instead of a person. A text goes to the managing director, to the office manager, to the foreman and to the son-in-law who "knows about the internet". Four responses arrive at four different times, two of them contradict each other, one never comes. Every round costs two to four working days, and after the third round the text is not better, only more cautious. Across a whole project that typically adds one to two extra weeks (project experience) without any work having been done.
A website does not improve because more people comment on it, but because one person decides and the others contribute.
The remedy is unspectacular: one person is named as the decision-maker, collects feedback internally and returns a single, binding version. Feedback gets a deadline — three working days is a common value. Anything arriving after that moves into the follow-up phase, not the current round. And there is a cap: two revision rounds per page. Agreeing these rules up front feels blunt when written down and saves three weeks of discussion later.
Bottleneck three: domain and DNS access, auth code included
The third bottleneck is the most treacherous, because it strikes right at the end — at the point with the least slack. The website is finished, the date is set, and then it turns out nobody knows where the domain is administered. The previous provider registered it "along the way", the credentials sit in a mailbox that no longer exists, and the contact is on holiday that week. The numbers show how ordinary this situation is: in June 2026 the number of registered .de domains passed the 18 million mark (DENIC); statistically that is almost one .de address for every sixth resident of Germany (DENIC). Every single one has an administrator — the only question is whether you know who it is.
When the registrar changes, the auth code comes into play, known as AuthInfo for .de domains. The current provider generates it on the domain holder's instruction and transmits it to the registry in encrypted form; the new provider submits it together with the transfer request (DENIC). The point that matters for the schedule: the code expires automatically after 30 days (DENIC) and then has to be requested again. Request it too early and then push go-live back six weeks, and you apply for it a second time — with the same wait at the old provider. Request it too late and you are waiting in the middle of the go-live window. The sensible corridor is roughly four weeks before the planned date. How domain, mailboxes and forwarding fit together in general is explained in the article on domain and business email basics.
Four questions that need answers four weeks ahead
Choosing the go-live window
Go-live is technically the shortest step of the entire project — and the only one where a mistake is visible immediately. That is why it deserves its own window with a run-up. The most important preparatory step is lowering the TTL: every DNS record carries a validity period telling other servers how long they may remember the answer. If that value is set to 24 hours, some visitors will still see the old website for a full day after the switch. Lowering the TTL to a few minutes 24 to 48 hours before the date shortens that window considerably — and it is raised back to its original value a few days after go-live.
- 48 hours before: set the TTL of the affected DNS records to a low value and test access to DNS administration one last time
- 24 hours before: document every mailbox, forwarding rule and MX record — a screenshot or export, not from memory
- The day before: have the list of existing addresses and their new targets ready so redirects take effect immediately after the switch
- On the day, in the morning: make the switch, then check the home page, two subpages, the form and the phone number yourself
- Within the first hour: send a test message to a mailbox on the domain and have receipt confirmed
- After 24 hours: check again that certificate, redirects and mail delivery are stable, then restore the TTL
No go-live on a Friday afternoon
The second point regularly overlooked at go-live is email. Domain and mailboxes hang off the same DNS records; thinking only about the website during the switch can make mailboxes unreachable without anyone noticing straight away — incoming messages then go nowhere and the sender gets an error message at best. So MX records and every forwarding rule should be documented before the switch and tested after it. The test is simple: a message from outside to every active mailbox, and a reply back.
Third: old addresses need a destination. When pages get new paths, links from directories, trade articles, email signatures and printed material run into nothing — and printed material cannot be corrected retroactively. The mapping of old to new addresses should exist before go-live and take effect with the switch, not a week later. How that mapping is built properly is covered at length in the article on relaunching without ranking loss; for the schedule it is enough to know the list must be finished the day before.
Seasonal planning: when a go-live sits well
A schedule is not only a question of weeks but also of months. A new website pays off when enquiries arrive — and enquiries are seasonal. At the same time, the input from the business needs exactly the calm that peak season does not offer. Together that yields a simple rule of thumb: go-live sits best shortly before demand rises, with the project phase before it in the quieter period. Reverse the two and you get a website nobody maintains and photos nobody takes.
| Sector | Good go-live window | Unfavourable | Reason |
|---|---|---|---|
| Heating and plumbing trades | Late summer to early autumn, before the heating season | In the middle of the heating season | Enquiries rise with the first cold spell; contributions are no longer feasible then |
| Restaurants with outdoor seating | Late winter to spring, before the terrace season | High summer | Menu, opening hours and reservations need to be in place before the rush |
| Medical practices and health professions | Late spring to early summer | Flu season in winter | During infection season there is not a minute to spare for sign-off and photo shoots |
| Clubs and voluntary organisations | Six to eight weeks before the general meeting | The week of the meeting itself | The meeting is a good occasion to present the new site — not to finish it |
| Landscaping and garden construction | Winter to early spring | April to June | The order peak coincides with the building season; winter leaves time for content |
| Consultancies, law and tax firms | Late summer or autumn | Year-end and filing deadlines | Deadlines tie up exactly the people who have to check the copy for accuracy |
One uncomfortable but useful consequence follows from this table: when the window gets tight, postponing beats pushing through. A go-live under pressure produces exactly the mistakes that cost weeks afterwards — half-finished copy, untested forms, forgotten redirects. A launch delayed by four weeks costs four weeks. A botched launch costs trust, and trust cannot be scheduled. Slack is therefore not a sign of poor planning but part of it: two weeks of reserve on a ten-week project is a realistic approach (project experience).
One day, one week, three months
"How fast can it be in the best case?" is a fair question, and it has three different answers depending on what is already prepared. The decisive difference is not the speed of the build but the state of the input. Starting on Monday with finished copy, cleared image rights and working domain access puts you in a completely different position from someone who still has to decide what the home page should say.
Doable in a day
A single, honest presence page: services in bullet points, a way to get in touch, opening hours, directions, imprint and privacy notice. Precondition: the details exist and the domain is accessible. That is not a stopgap but a base that holds — as long as it is not sold as a finished website.
Doable in a week
A small website of five to eight pages, provided copy exists at least in draft, usable photos are available and one person can sign off at short notice. Legal pages, consent and a test on a phone are part of it. What is missing after that week is polish, not substance.
Needs three months
Several locations or language versions, an extensive service catalogue, new photography, coordinated legal texts across multiple entities, a move involving many legacy addresses. Here the time sits in coordination and input, not in the build.
One warning belongs with every fast option: speed must not come at the cost of load time. 53 percent (Think with Google) of mobile visits are abandoned when a page takes longer than three seconds to load. How strongly that plays out is shown by a case study from a European car manufacturer: improving Largest Contentful Paint by one second went along with 14 percentage points (Google web.dev, Renault case study) fewer bounces and 13 percent (Google web.dev, Renault case study) more conversions; the analysis covered more than ten million visits across 33 countries (Google web.dev, Renault case study). A website built in a day that loads in four seconds is not a time saving. What role usability on small screens plays here is described in the article on mobile usability for business websites.
How to spot an unrealistic schedule
Unrealistic schedules are rarely malicious. Mostly they arise because input from the business does not appear as a work package but as a given. A few warning signs are visible at first glance at the plan — regardless of who drew it up.
- Input from the business does not appear in the plan at all, only the build steps
- There is no date for photography, although nobody can claim usable images exist
- Sign-off appears without names: "client reviews" instead of "Ms Meier signs off by Friday"
- Legal pages, consent and accessibility show up as the last item before go-live rather than as their own phase
- Go-live falls on a Friday, right before a company shutdown, or in the week of the annual accounts
- No separate step is planned for domain and DNS access, although the domain sits with the previous provider
- There is not a single day of slack between the last correction and go-live
- The plan ends at go-live — follow-up, corrections and a first review are missing entirely
The cross-check in one sentence
The process in five steps — and which phases get shorter
Not all seven phases are equally unavoidable. Part of the effort exists because the same foundations get rebuilt in every project: a sensible site structure, a set of legal pages, a consent mechanism, fast delivery, a usability check. When those building blocks are prepared, the schedule does not shift because the work happens faster, but because entire waiting periods disappear. At XICflow the process therefore looks like this:
Details about the business
Services, audience, catchment area, tone of voice and a named decision-maker. This replaces the classic briefing and usually takes one session rather than one week.
Services, audience, catchment area, tone of voice and a named decision-maker. This replaces the classic briefing and usually takes one session rather than one week.
What disappears is not the responsibility of the business but the waiting time between phases. Photos, factual accuracy and sign-off remain the company's job — no tool changes that. What changes is the order: instead of waiting six weeks for a draft and then supplying content, the draft comes first and the input flows straight into it. How the three usual routes — website builder, agency, AI-assisted build — differ in effort and ownership is compared in the article on website builder, agency or AI; how that affects cost and duration is shown in the overview of plans.
Legal pages and accessibility do not belong at the end
That leaves the item that is hardest to plan and still belongs in every schedule: the follow-up. Two weeks after go-live it becomes clear which pages are actually opened, which form submissions arrive and where visitors drop off. Those two weeks are not leftover work but the project's first meaningful feedback. Anyone who wants to see how varied finished results can look will find different sectors and structures among the example websites; the building blocks behind them are shown in the overview of features. For open scheduling questions about a specific project, direct contact is the quickest route.
Sources and studies