De livegang van een webproject wordt behandeld als de finish. Het champagne-moment. Alles staat online, de factuur is voldaan en de samenwerking lijkt afgerond. Maar in de projecten die ik bouw, is de oplevering eerder het punt waarop de echte vragen beginnen. Wie past straks kleine teksten aan? Wat gebeurt er als er een fout opduikt na drie maanden? Hoe worden software-updates verwerkt? Dat soort vragen zijn onderdeel van een goed project, maar worden zelden besproken voordat de eerste lijn code wordt geschreven.
De stille periode na go-live
Direct na de livegang is er doorgaans een korte periode van rust. De site of applicatie draait, jij bent tevreden en de developer heeft het project in principe afgerond. Wat daarna volgt, verschilt sterk per samenwerking. In sommige gevallen is er een afgesproken garantieperiode, waarin gevonden fouten kosteloos worden opgelost. In andere gevallen wordt elk contactmoment na oplevering al gefactureerd als nieuw werk.
Wat je in die eerste weken na lancering regelmatig ziet: kleine onvolkomenheden die tijdens de acceptatietest niet opvielen. Een formulier dat op een bepaald apparaat toch net even anders reageert, een tekst die in mobiele weergave te lang uitloopt of een melding die in een edge case toch een verkeerde waarde toont. Dit zijn geen grote problemen, maar ze vragen wel om een moment van aandacht. Als je niet van tevoren hebt afgesproken hoe dit wordt opgepakt, loop je het risico in een vaag gesprek te belanden over "is dit nu meerwerk of niet."
Wat ik mijn opdrachtgevers altijd meegeef: maak een bewuste afspraak over wat er na oplevering valt onder de oorspronkelijke opdracht en wat er als losse begeleiding wordt beschouwd. Dat gesprek moet je voeren vóór de livegang, niet erna.
Onderhoud is geen vanzelfsprekendheid
Een webapplicatie of portaal is geen printer die je aansluit en daarna vergeet. De software waarop het gebouwd is, krijgt beveiligingsupdates. De server waarop het draait, vereist regelmatige aandacht. En de browser die jouw bezoekers gebruiken, verandert meermaals per jaar in wat het ondersteunt en hoe het dingen weergeeft.
Bij maatwerksoftware geldt dat in verhoogde mate. Er is geen community van duizenden developers die patches publiceert, zoals bij WordPress of een populair CMS. Jij bent afhankelijk van de developer die het systeem heeft gebouwd, of van iemand die bereid is er zich in te verdiepen. Dat is geen argument tegen maatwerk, het is een reden om onderhoud serieus te plannen. Een framework als Laravel, waar ik mee werk, heeft een heldere releasecyclus met langetermijnondersteuning per versie. Dat weet ik als developer, maar jij als ondernemer hoeft dat niet bij te houden. Wat je wel moet weten: vraag bij de start van een project expliciet naar een onderhoudsvoorstel en wat er gebeurt als jij dat niet afneemt.
Zonder enige vorm van onderhoud is een webapplicatie na twee à drie jaar vaak technisch verouderd. Dat betekent niet dat het stopt met werken, maar het betekent wel dat updates aan de omgeving er onverwacht voor kunnen zorgen dat bepaalde onderdelen niet meer naar behoren functioneren. Een kleine investering per kwartaal voorkomt een grote herstelklus die veel meer kost dan het onderhoud zelf.
Wie beheert de inhoud en wie beheert het systeem
Er is een verschil tussen wat jij zelf doet na de livegang en wat de developer beheert. Dat onderscheid wordt in gesprekken over een nieuw project soms slordig behandeld. Jij wil zelf teksten aanpassen, een product toevoegen of een nieuw teamlid in het portaal aanmaken. Dat is prima, en een goed gebouwd systeem maakt dat makkelijk voor je. Maar de onderliggende techniek, de serverconfiguratie, de SSL-verlenging, de databaseback-ups en de frameworkupdates zijn iets anders.
Vraag jezelf bij de start van een project af: welke beheertaken wil ik zelf uitvoeren en welke leg ik neer bij de developer? Dat bepaalt mede hoe een systeem wordt gebouwd. Als jij zelf teksten wil beheren, heeft het CMS-gedeelte aandacht nodig. Als jij gebruikers wil aanmaken en verwijderen, moeten die rechten op een veilige manier beschikbaar zijn. Als de developer ook na livegang het systeem beheert, moeten er afspraken zijn over responstijd, beschikbaarheid en wat er precies onder dat beheer valt.
Neem een zakelijke dienstverlener die een klantportaal laat bouwen. Die wil zelf contracten uploaden, klantdossiers bijwerken en gebruikers uitnodigen. Dat lukt met een goed ingerichte beheerpagina. Maar de koppeling met de externe opslagdienst, de beveiligingsinstellingen of de back-upstrategie zijn geen taken die je als ondernemer zomaar zelf oppakt. Die grens helder benoemen voorkomt dat je na een jaar merkt dat niemand die taak had opgepakt.
Wat je moet vragen voordat je tekent
Samenwerken met een freelance developer is persoonlijk en flexibel, maar het vergt ook dat jij als opdrachtgever weet welke vragen je moet stellen. Niet over technologie, maar over continuïteit. Wat is de responstijd als er iets mis gaat? Hoe worden back-ups gemaakt en hoe snel kan iets worden hersteld? Is de broncode van het project van jou, of blijft die bij de developer? Wat kost een uur extra werk buiten de opdracht?
Die laatste vraag verdient extra aandacht. Zodra een project is opgeleverd en je meer wil, start een nieuwe zakelijke relatie. De tarieven, de manier van werken en de prioritering van jouw vraag kunnen anders zijn dan tijdens het project zelf. Als jij na zes maanden een nieuwe module wil toevoegen, is het prettig als je weet wat dat gaat kosten en hoe lang het gaat duren. Niet vervelend om naar te vragen, gewoon zakelijk verstandig.
Verder is het slim om te weten waar het systeem draait en wie toegang heeft tot de server. Soms host een developer een project op eigen naam, waarbij jij afhankelijk bent van diens account bij een hostingpartij. Als de samenwerking stopt, kan het omslachtig zijn om dat over te dragen. Beter is een constructie waarbij de hosting op jouw naam staat en de developer er toegang toe heeft gekregen. Dat geeft jou meer controle en minder risico bij een eventuele wisseling.
Zelf werk ik met een duidelijke overdrachtsafspraak aan het einde van elk project. Jij krijgt toegang tot de coderepository, de server en alle externe diensten. Documentatie over hoe de applicatie werkt, hoort daarbij. Dat voelt misschien als een detail, maar het is het bewijs dat een project écht van jou is.
Naoplevering is ook het moment waarop je kunt nadenken over doorontwikkeling. Een eerste versie van een webapplicatie is zelden de eindversie. Gebruikers geven feedback, processen veranderen, of je ziet kansen om een functie uit te breiden. Dat is gezond. Hoe beter de eerste versie is gedocumenteerd en gebouwd, hoe makkelijker die doorontwikkeling verloopt. Een slecht gefundeerd systeem maakt elke wijziging later duurder dan hij zou moeten zijn.
Als jij een webapplicatie, portaal of webshop laat bouwen, wil je weten dat de relatie na de livegang duidelijk is. Niet vaag, niet afhankelijk van goodwill, maar gewoon helder vastgelegd. Dat begint bij de juiste vragen stellen voordat je akkoord gaat, en het eindigt bij een developer die die vragen serieus neemt. Op https://pimvdmolen.nl/diensten/maatwerk-ontwikkeling kun je lezen hoe ik maatwerkopdrachten aanpak, inclusief wat er na de oplevering geregeld is. Wil je daar een gesprek over, neem dan contact op via https://pimvdmolen.nl/contact.