With us, a website goes live in 3 to 6 weeks on average. An app or AI integration usually takes 6 to 12 weeks, simply because it involves more technology and more testing. These timelines are indicative: the scope of your project ultimately determines the planning.
What influences the timeline most
The build time itself is usually not the biggest variable, but how quickly content, images and feedback come in from your side. A project where all copy and photos are ready goes demonstrably faster than one where they are delivered along the way.
Why we work in short sprints
Instead of only showing something after weeks, we work in short, reviewable sprints. You see a working version along the way, can adjust course before something is "finished", and avoid major changes of direction at the end of a project.
An example week-by-week schedule
For an average website of four to six weeks, a project looks roughly like this. Week 1: introductory call, agreeing scope and structure, start of the design. Week 2: first design for review, feedback round. Weeks 3 and 4: building the approved designs, first working version available to click through. Week 5: adding content, testing on different devices and browsers, small adjustments. Week 6: final checks, connecting the domain and hosting, launch.
Larger projects with custom functionality follow the same rhythm, but with extra sprints between build and launch for the functionality that needs more testing, such as a payment process or an integration with an external system.
What usually causes delays
In practice it is rarely technical problems that make a timeline slip. More often it is a feedback round that takes longer than planned, content delivered halfway while the structure waits for it, or scope that grows during the project with "could we just add this". Each is understandable on its own, but they pile up if nobody actively steers.
That is why we work with clear milestones and one point of contact on each side: you know exactly when we need something from you, and we show what each sprint delivered. It prevents a project from stalling because nobody knows who is waiting for whom.
Going live sooner: what you can do
The biggest acceleration is on your side, not ours. Having content and images ready before the build phase starts saves one to two weeks on average. Responding quickly to review rounds (within a few days rather than two weeks) keeps the momentum. And it helps to agree internally on structure and message beforehand, so feedback does not change halfway because of an internal discussion held too late.
When a longer timeline is actually wise
Not every project benefits from going live as fast as possible. With a full rebrand, a website that has to convince several departments or stakeholders, or content that still needs to be written by a copywriter, building in more room is more realistic than holding on to a tight deadline that will not be met anyway. We say so honestly in the introductory call: an optimistic schedule that does not hold helps nobody.
How we organise feedback along the way
Instead of separate emails with screenshots, we use a shared test environment where you can view the current state of the project at any time, on your own phone or laptop. That avoids the delay of collecting feedback in a separate document and sending it all at once: small points you pass on immediately, bigger ones we discuss in a short scheduled moment, so nobody has to wait for anyone.
It also means there is never a big "reveal" where you see the result for the first time. By the time a project goes live, you have seen it take shape several times and helped steer the direction, instead of reacting afterwards to something that is already finished.
What happens in the last week before launch
The last week is mostly checking, not building: proofreading all copy again, testing links, actually submitting forms to check notifications arrive, and testing the site on the main browsers and devices. Just before launch the domain is connected to the hosting, and after launch we check that everything works in practice, including SSL certificates and email configuration.
This final round is exactly why "almost done" usually still takes a few days: it is no longer building, but carefully validating that everything does what it should before it goes public.
Larger projects: apps and AI integrations
For apps and AI integrations, which usually take 6 to 12 weeks with us, there is an extra testing phase compared to a website: functional testing on several devices and operating systems, and for AI integrations a period in which the system is trained and tested on real, representative questions before it goes live. That extra time is not a delay; it is the phase where problems are found before users run into them, which is far cheaper than fixing a bug after hundreds of people are already using the app.
What a realistic schedule gives you
A schedule that accounts for feedback rounds, content delivery and testing looks less impressive on paper than one promising "live in two weeks", but in practice it is almost always met. We would rather give a realistic estimate that holds than an optimistic one that leads to disappointment and rushed work in the final days. A project delivered on time and with care is a better outcome for everyone than one finished faster but sloppier.
What if you really must go live sooner
Sometimes there is a hard deadline, such as a trade fair, a product launch or an expiring contract. In those cases we discuss honestly which scope is achievable in the time available: better a more compact website that goes live on time and without errors than an extensive one that misses the deadline or sacrifices quality under time pressure. A phased approach, with the core live on time and extensions in the following weeks, is often the wisest solution.
Why "fast" and "cheap" are not the same
A common misconception is that a faster timeline is automatically cheaper. It is not: doing the same work in less time often requires more simultaneous effort, which tends to raise the price rather than lower it. A longer, calmer schedule is both cheaper and less error-prone for most projects. We always discuss this explicitly when a deadline is tight: faster is possible, but it has a price, and it is better to know that upfront than afterwards.