Twee offertes voor dezelfde webapplicatie kunnen duizenden euro's uit elkaar liggen, terwijl de omschrijvingen op het eerste gezicht bijna identiek zijn. Dat klinkt vreemd, maar het klopt. De ene partij rekent ontwerp, testfase en technische documentatie standaard mee. De andere gooit die kosten er later bij, of laat ze volledig weg zodat je er na oplevering zelf tegenaan loopt. Wie alleen naar het totaalcijfer kijkt, vergelijkt appels met peren en heeft dat door het tekenen heen niet door.
Wat er in een offerte moet staan, en wat er vaak ontbreekt
Een goede offerte beschrijft niet alleen wat er gebouwd wordt, maar ook wat er expliciet buiten de scope valt. Dat tweede punt is net zo belangrijk als het eerste. Zit er geen "buiten scope" sectie in de offerte die je ontvangt, dan is de kans groot dat je later voor verrassingen staat: een koppeling met jouw boekhoudsoftware die toch apart geprijsd blijkt, of een exportfunctie die "niet standaard" blijkt te zijn.
Concrete gebruikersverhalen of functionele specificaties horen thuis in een serieuze offerte. Niet "dashboardomgeving voor beheerder", maar: welke acties kan een beheerder uitvoeren, op welke gegevens, met welke rechten? Hoe specifieker de omschrijving, hoe minder ruimte er is voor interpretatieverschillen. Ontbreekt die specificiteit volledig, dan is de kans reëel dat jij iets anders voor ogen hebt dan de developer die het bouwt.
Vraag ook altijd naar de aanpak rond wijzigingen na oplevering. Staat er een onderhoudscontract bij, of rekent de partij elk klein aanpassingsverzoek als los uurwerk? Dat onderscheid bepaalt je totale jaarkosten meer dan de initiële bouwprijs.
Uurtarief versus vaste prijs: wat past bij welk project
Projecten met een helder omschreven scope lenen zich goed voor een vaste prijs. Weet je exact welke schermen er nodig zijn, welke koppelingen er moeten komen en hoe de datastructuur eruitziet, dan kan een developer daar een eerlijk bedrag op plakken. Het voordeel is zekerheid aan jouw kant: het eindigt niet plotseling op een budget dat ver boven de afspraak uitstijgt.
Zodra de scope echter nog in beweging is, of zodra je van plan bent om gaandeweg bij te sturen op basis van gebruikersfeedback, werkt een vaste prijs averechts. De developer bouwt dan wat er in de offerte staat, terwijl jij intussen een beter idee hebt gekregen van wat je eigenlijk wil. Dat levert fricties op, en elke afwijking van de originele beschrijving wordt een discussie over meerwerk. In zulke trajecten is uurwerk of een sprint-gebaseerde aanpak eerlijker voor beide kanten.
Wat ik in mijn eigen trajecten doe is aan het begin van een project altijd vaststellen hoe zeker de scope is. Staat alles vast, dan werk ik met een vaste prijs inclusief duidelijke grenzen. Is er nog ruimte om bij te sturen, dan stel ik voor om per fase te werken: eerst een begroting voor de eerste fase, daarna opnieuw inschatten op basis van wat de eerste oplevering heeft opgeleverd aan inzichten. Dat voorkomt dat je aan het einde van een traject betaalt voor een versie die je eigenlijk nooit had gewild.
De verborgen kosten na oplevering
De bouwprijs is zelden de duurste post op de lange termijn. Hosting, domeinnaam en ssl-certificaten zijn nog de makkelijkste categorieën om op voor te bereiden. Wat echt geld kost, is het onderhoud van de applicatie zelf: beveiligingsupdates, aanpassingen als koppelingen met externe systemen veranderen, en nieuwe features die je na een jaar gebruik toch nodig blijkt te hebben.
Zit je vast aan een partij die geen duidelijkheid geeft over hoe de applicatie is opgebouwd, dan is de stap naar een andere developer later groter dan je denkt. Applicaties die gebouwd zijn zonder documentatie, zonder duidelijke structuur in de code en zonder versiegeschiedenis zijn voor een nieuwe developer een tijdrovend startpunt. Die uren betaal jij. Vraag daarom altijd of de code na oplevering van jou is, of de broncode in een repository staat die jij beheert en of er documentatie wordt opgeleverd.
Licentiekosten zijn een categorie die in offertes structureel te weinig aandacht krijgt. Werkt de applicatie met externe services voor e-mail, zoekindexering, betalingen of datakoppelingen, dan gelden daar maandelijkse of jaarlijkse kosten voor. Een applicatie die intern zoeken aanbiedt via een externe zoekmachine-as-a-service kan je op jaarbasis honderden tot duizenden euro's kosten, afhankelijk van het volume. Vraag naar elk extern platform dat in de applicatie wordt ingezet en wat de structurele kosten daarvan zijn.
Hoe je offertes vergelijkt zonder er een dagtaak van te maken
Het vergelijken van offertes gaat makkelijker als je vooraf een vaste lijst met vragen opstelt die je aan elke partij stelt. Niet als een formele aanbesteding, maar gewoon als basisinformatie die je nodig hebt om een eerlijke vergelijking te maken. Denk aan: welke technieken worden ingezet en wat is de reden voor die keuze, hoe wordt de applicatie getest voor oplevering, wie is er verantwoordelijk als er na oplevering iets kapot gaat en binnen welke termijn wordt dat opgepakt?
Let ook op hoe een partij omgaat met je vragen. Een developer die jouw vragen kort afdoet of snel naar het contract wil, is een ander signaal dan iemand die de tijd neemt om uit te leggen waarom bepaalde keuzes in de architectuur worden gemaakt. Het gesprek voor de offerte zegt veel over hoe het gesprek er tijdens het project uitziet.
Ik kijk in offertes die ik zelf beoordeel altijd naar de verhouding tussen ontwerp en bouw. Een offerte die vrijwel alles toewijst aan development en nauwelijks budget reserveert voor overleg, ontwerp en testcycli, is doorgaans te krap begroot. Applicaties bouwen gaat niet alleen over code schrijven: een behoorlijk deel van de tijd gaat op aan afstemming, iteratie en verificatie. Staat dat niet in de begroting, dan staat het er later toch in, alleen als meerwerk of als gesneden kwaliteit.
Vergelijk offertes dus niet op het totaalbedrag, maar op de dekking van het traject. Een offerte van 18.000 euro die ontwerp, technische specificatie, bouw, testing en een maand nazorg omvat, is in de meeste gevallen voordeliger dan een offerte van 12.000 euro die begint bij de bouw en stopt bij oplevering. Die resterende 6.000 euro duikt ergens anders op, dat is vrijwel zeker.
Zelf neem ik de tijd om voor elk traject eerst goed door te spreken wat er gebouwd moet worden, welk probleem het oplost en welke randvoorwaarden er gelden. Pas daarna maak ik een offerte. Dat kost meer tijd aan de voorkant, maar het scheelt frustraties, discussies over meerwerk en teleurgestelde klanten aan de achterkant. Een offerte is uiteindelijk geen formaliteit, het is het fundament waarop het hele project rust. Een zwak fundament merk je altijd, al is het soms pas halverwege de bouw.
Als je een webapplicatie, portaal of webshop wil laten bouwen en wil weten hoe ik dat aanpak, dan vind je daar meer informatie over op https://pimvdmolen.nl/diensten/webapplicaties. Wil je direct een gesprek of een offerte aanvragen, neem dan contact op via https://pimvdmolen.nl/contact. Ik denk graag mee, ook als je nog niet precies weet wat je nodig hebt.