Een website staat bij ons gemiddeld binnen 3 tot 6 weken live. Een app of AI-integratie duurt meestal 6 tot 12 weken, simpelweg omdat er meer techniek en meer testwerk in zit. Deze termijnen zijn indicatief: de scope van jouw project bepaalt uiteindelijk de planning.
Wat de tijdlijn het meest beïnvloedt
Niet de bouwtijd zelf is meestal de grootste variabele, maar hoe snel content, beeldmateriaal en feedback vanuit jouw kant binnenkomen. Een project waarbij alle teksten en foto's al klaarstaan, gaat aantoonbaar sneller dan een project waarbij dat gaandeweg wordt aangeleverd.
Waarom wij in korte sprints werken
In plaats van pas na weken iets te laten zien, werken wij in korte, reviewbare sprints. Zo zie je tussentijds al een werkende versie, kun je bijsturen voordat iets is "af", en voorkom je dat er aan het einde van een traject nog grote koerswijzigingen nodig zijn.
Een week-voor-week voorbeeldplanning
Voor een gemiddelde website van vier tot zes weken ziet een traject er ongeveer zo uit. Week 1: kennismakingsgesprek, vaststellen van scope en structuur, start van het ontwerp. Week 2: eerste ontwerp ter review, feedbackronde. Week 3 en 4: bouw van de goedgekeurde ontwerpen, eerste werkende versie beschikbaar om doorheen te klikken. Week 5: content invoegen, testen op verschillende apparaten en browsers, kleine aanpassingen. Week 6: laatste controles, koppeling met domeinnaam en hosting, livegang.
Grotere trajecten met maatwerkfunctionaliteit volgen hetzelfde ritme, maar met extra sprints tussen bouw en livegang voor de functionaliteit die meer testwerk vraagt, zoals een betaalproces of een koppeling met een extern systeem.
Wat vertraging meestal veroorzaakt
In de praktijk zijn het zelden technische problemen die een tijdlijn laten uitlopen. Vaker is het een feedbackronde die langer op zich laat wachten dan gepland, content die pas halverwege het traject wordt aangeleverd terwijl de structuur daarop wacht, of een scope die tijdens het traject alsnog groeit met "kan er nog even dit bij". Elk van deze dingen is op zichzelf begrijpelijk, maar ze stapelen op als er niet actief op gestuurd wordt.
Daarom werken wij met duidelijke mijlpalen en een vast aanspreekpunt aan beide kanten: jij weet precies wanneer we iets van jou nodig hebben, en wij laten zien wat er middels de sprint is opgeleverd. Dat voorkomt dat een project stilvalt omdat niemand meer weet wie op wie wacht.
Sneller live: wat jij kunt doen
De grootste versnelling zit aan jouw kant, niet aan de onze. Content en beeldmateriaal klaar hebben vóór de bouwfase begint, scheelt gemiddeld een tot twee weken. Snel reageren op reviewrondes (binnen een paar dagen in plaats van na twee weken) houdt het momentum erin. En het helpt om vooraf binnen je eigen organisatie overeenstemming te hebben over de structuur en boodschap, zodat feedback niet halverwege het traject alsnog verandert door een interne discussie die pas laat wordt gevoerd.
Wanneer een langere tijdlijn juist verstandig is
Niet elk project is gebaat bij zo snel mogelijk live gaan. Bij een volledige rebranding, een website die meerdere afdelingen of stakeholders moet overtuigen, of content die nog geschreven moet worden door een tekstschrijver, is meer ruimte inbouwen realistischer dan vasthouden aan een krappe deadline die toch niet gehaald wordt. Wij geven dat eerlijk aan tijdens het kennismakingsgesprek: een optimistische planning die niet standhoudt, helpt niemand verder.
Hoe wij tussentijdse feedback organiseren
In plaats van losse e-mails met screenshots, werken wij met een gedeelde testomgeving waar je op elk moment de actuele stand van het project kunt bekijken, op je eigen telefoon of laptop. Dat voorkomt de vertraging die ontstaat wanneer feedback pas verzameld wordt in een los document en dan in één keer wordt teruggekoppeld: kleine punten kun je meteen doorgeven, grotere punten bespreken we in een kort gepland moment, zodat niemand op elkaar hoeft te wachten.
Deze aanpak betekent ook dat er nooit een groot "reveal-moment" is waarop je voor het eerst het resultaat ziet. Tegen de tijd dat een project live gaat, heb je het al meerdere keren in wording gezien en meegedacht over de richting, in plaats van achteraf te reageren op iets dat al af is.
Wat er gebeurt in de laatste week voor livegang
De laatste week bestaat voornamelijk uit controlewerk, niet uit nieuwe bouw: alle teksten nogmaals controleren op typefouten, links testen, formulieren daadwerkelijk versturen om te controleren of meldingen goed binnenkomen, en de site testen op de belangrijkste browsers en apparaten. Vlak voor livegang wordt de domeinnaam gekoppeld aan de hosting, en na livegang controleren we of alles ook in de praktijk goed werkt, inclusief zaken als SSL-certificaten en e-mailconfiguratie.
Deze laatste controleslag is precies waarom "bijna klaar" meestal nog een paar dagen kost: het is niet meer bouwen, maar zorgvuldig valideren dat alles doet wat het moet doen voordat het publiek toegankelijk wordt.
Grotere projecten: apps en AI-integraties
Bij apps en AI-integraties, die bij ons meestal 6 tot 12 weken duren, komt er een extra testfase bij ten opzichte van een website: functioneel testen op meerdere apparaten en besturingssystemen, en bij AI-integraties een periode waarin het systeem wordt getraind en getest op echte, representatieve vragen voordat het live gaat. Deze extra tijd is geen vertraging, het is de fase waarin problemen worden gevonden vóórdat gebruikers ertegenaan lopen, wat aanzienlijk goedkoper is dan een bug oplossen nadat honderden mensen de app al gebruiken.
Wat een realistische planning je oplevert
Een planning die rekening houdt met feedbackrondes, contentaanlevering en testtijd is minder indrukwekkend op papier dan een planning die belooft "in twee weken live", maar wordt in de praktijk vrijwel altijd gehaald. Wij geven liever een realistische inschatting die klopt, dan een optimistische inschatting die leidt tot teleurstelling en haastwerk in de laatste dagen. Een project dat op tijd en zorgvuldig wordt opgeleverd, is voor iedereen een betere uitkomst dan een project dat sneller maar slordiger wordt afgerond.
Wat als je sneller live móet
Soms is er een harde deadline, bijvoorbeeld een beurs, een productlancering of een lopend contract dat afloopt. In die gevallen bespreken we eerlijk welke scope wél haalbaar is binnen de beschikbare tijd: liever een compactere website die op tijd en foutloos live gaat, dan een uitgebreide website die de deadline niet haalt of onder tijdsdruk kwaliteit inlevert. Een gefaseerde aanpak, waarbij de kern op tijd live gaat en uitbreidingen volgen in de weken erna, is vaak de meest verstandige oplossing bij een harde deadline.
Waarom "snel" en "goedkoop" niet hetzelfde zijn
Een veelvoorkomend misverstand is dat een snellere tijdlijn automatisch goedkoper is. Dat klopt niet: hetzelfde werk in minder tijd uitvoeren vraagt vaak juist meer gelijktijdige inzet, wat de prijs eerder verhoogt dan verlaagt. Een langere, rustigere planning is voor de meeste projecten zowel goedkoper als minder foutgevoelig dan een versnelde planning. Wij bespreken dit altijd expliciet wanneer een deadline krap is: sneller kán, maar heeft een prijs, en het is beter dat vooraf te weten dan achteraf.