Webdesignoffertes vergelijken: kijk verder dan de bouwprijs

De laagste prijs kan een goede keuze zijn wanneer het voorstel precies past. Een hoger bedrag kan terecht zijn wanneer er aantoonbaar meer onderzoek, inhoud, techniek of begeleiding nodig is. Zonder een gezamenlijke omschrijving van de opdracht vergelijk je vooral aannames. Begin daarom bij het werk, en pas daarna bij het totaalbedrag.

Een offerte hoeft niet elk ontwerpdetail vooruit te beschrijven. Wel moet duidelijk zijn welke vragen al zijn beantwoord, welke tijdens het project worden onderzocht en wat er gebeurt als de uitkomst de omvang verandert. Daar zit vaak het verschil tussen een beheersbare opdracht en discussies achteraf.

Beschrijf wat de website voor bezoekers en je organisatie moet doen. Welke doelgroep komt waarvoor? Welke pagina’s en functies zijn noodzakelijk? Wat moet worden overgenomen uit de huidige website? Wie levert teksten, fotografie, vertalingen en toegang tot bestaande systemen?

Maak onbekende onderdelen zichtbaar. “We willen een koppeling met ons CRM” is nog geen volledige opdracht. Het maakt uit welke gegevens worden uitgewisseld, wanneer dat gebeurt en wat bij fouten nodig is. Vraag een aanbieder om de onzekerheid eerst te onderzoeken of als afzonderlijke fase te begroten.

Vermeld ook beperkingen die iedere partij moet kennen: een lopend contract, vaste lanceringsdatum, beperkte interne beschikbaarheid of een verouderd systeem. Een voorstel dat hiermee rekening houdt lijkt soms duurder dan een voorstel waarin die omstandigheden nog niet zijn meegenomen.

Bij AOV Kompas leverde de opdrachtgever het contentplan aan. Magic Bytes werkte dat uit in tientallen informatiepagina’s, met vaste templates en aandacht voor leesbaarheid. Voor een offerte maakt die taakverdeling verschil: schrijven vanaf nul is een andere opdracht dan aangeleverde inhoud structureren, vormgeven en bouwen.

Tien pagina’s kunnen tien varianten van één indeling zijn, maar ook tien verschillende bezoekersroutes. Vraag welke unieke paginaopbouwen, formulieren en inhoudstypen worden ontworpen en gebouwd. Controleer wat een redacteur daarna zelf kan toevoegen.

Gebruik deze vergelijkingsvragen bij ieder voorstel. Laat onduidelijke antwoorden schriftelijk aanvullen voordat je een keuze maakt.

“Content door opdrachtgever” kan betekenen dat je alleen een tekstbestand aanlevert, of dat je zelf alles in het CMS zet en controleert. Dat verschil kost tijd. Hetzelfde geldt voor migratie: het overzetten van teksten is niet automatisch hetzelfde als het behouden van relevante URL’s en het controleren van verwijzingen.

Woorden als professioneel, gebruiksvriendelijk en SEO-klaar zijn nuttige ambities, maar onvoldoende als opleverafspraak. Spreek af hoe de belangrijkste taken worden gecontroleerd en welke onderdelen de aanbieder daarbij meeneemt.

Vraag bij mobiel bijvoorbeeld niet alleen of de website responsive is. Laat vastleggen dat navigatie, formulieren, foutmeldingen en belangrijke inhoud op afgesproken schermbreedtes worden getest. Laat ook toetsenbordbediening en duidelijke focus meenemen. De eerste toegankelijkheidscontroles van W3C maken concreet wat je kunt bekijken; een paar controles betekenen niet dat volledige conformiteit is aangetoond.

Bij snelheid helpt een afgesproken meetmethode meer dan “altijd supersnel”. Welke pagina’s worden onderzocht, met welke inhoud en onder welke omstandigheden? Welke scripts van derden vallen buiten de directe invloed van de bouwer? Vraag om de meetuitkomst en om een begrijpelijke uitleg van eventuele beperkingen.

Laat “SEO inbegrepen” uitwerken. Gaat het om technische toegankelijkheid, paginatitels, een sitemap, redirects en controle van indexeerbaarheid? Of ook om onderzoek, redactie en doorlopende verbetering? De SEO-richtlijnen voor ontwikkelaars van Google beschrijven concrete technische aandachtspunten. Ze zijn geen belofte van een bepaalde positie in de zoekresultaten.

Spreek af wanneer je tussentijds kunt beoordelen en wie namens je organisatie besluiten neemt. Een vast aantal feedbackrondes zegt weinig wanneer niet duidelijk is wat daarin wordt beoordeeld. Feedback op het eerste ontwerp is een andere stap dan controle van een werkend formulier.

Vraag om een acceptatieronde met echte inhoud en de belangrijkste bezoekers- en beheertaken. Leg vast welke bevindingen voor lancering moeten worden opgelost en hoe over overige punten wordt besloten. Zorg dat de persoon die later gaat beheren ook daadwerkelijk in het systeem werkt voordat je het als overgedragen beschouwt.

Een fictief voorbeeld: de offerte noemt een aanvraagformulier. Tijdens de controle blijkt dat de bevestigingsmail wel naar de bezoeker gaat, maar de aanvraag niet bij het juiste team terechtkomt. Een afspraak over de complete route maakt duidelijk dat dit geen cosmetisch detail is. Test daarom tot en met ontvangst en opvolging, niet alleen tot de verzendknop.

Vraag of het voorstel een vaste prijs voor een afgebakende opdracht bevat of een raming op basis van uren en aannames. Laat bij een raming vastleggen welke tarieven gelden, hoe het verbruik wordt gerapporteerd en welk budgetplafond je afspreekt. Een vaste prijs geeft alleen duidelijkheid als ook duidelijk is welke werkzaamheden en afhankelijkheden erbij horen.

Spreek af dat extra werk pas begint na jouw schriftelijke akkoord. Laat de aanbieder vooraf beschrijven wat erbij komt, waarom het buiten de afgesproken opdracht valt en wat de gevolgen zijn voor kosten en planning. Maak onderscheid tussen het herstellen van een afwijking van de afgesproken oplevering en een nieuwe wens. Zo wordt niet iedere correctie automatisch een uitbreiding.

Vraag bij een wijziging om een bedrag of raming, het toepasselijke tarief en eventueel een afzonderlijk plafond. Spreek ook af wanneer je een waarschuwing krijgt dat een raming of plafond in zicht komt. Leg vast wat er gebeurt als je niet akkoord gaat: blijft de oorspronkelijke opdracht uitvoerbaar, vervalt de toevoeging of moet de planning worden herzien?

Controleer ten slotte de betaalmomenten. Koppel iedere termijn aan een duidelijk beschreven moment of resultaat, zoals de start, een geaccepteerd ontwerp of de oplevering. Maak zichtbaar wanneer abonnementen en onderhoud ingaan. Zo vergelijk je naast de totale investering ook hoeveel je op welk moment betaalt en welke prestatie daar tegenover staat.

Zet eenmalige kosten naast vaste en variabele kosten. Hosting, onderhoud, licenties, ondersteuning, betaalde koppelingen en inhoudelijk beheer kunnen afzonderlijk of als pakket zijn aangeboden. Noteer wat verplicht is, wat optioneel is en wat er bij groei verandert.

Kies voor alle voorstellen dezelfde vergelijkingsperiode die past bij je planning. Neem daarin de bouw, afgesproken abonnementen en voorzienbaar beheer op. Houd uitbreidingen die nog niet zijn besloten apart. Anders wordt een onzekere toekomstverwachting ten onrechte een precies totaalbedrag.

Controleer ook de rekeneenheid. Een tarief per uur, per website, per gebruiker of per hoeveelheid verkeer geeft andere gevolgen. Vraag welke limieten gelden en wanneer overleg nodig is. Een laag instaptarief is pas te beoordelen als duidelijk is welke gebruikssituatie daarin past.

Bij onderhoud wil je weten wat daadwerkelijk wordt gedaan. Alleen updates installeren is iets anders dan updates testen, back-ups bewaken en herstel uitvoeren. De WordPress-documentatie over updates en back-ups laat zien waarom deze onderdelen samenhangen. Welke partij dat voor jouw website doet, moet uit de afspraken blijken.

Vraag op wiens naam het domein, de hosting en belangrijke diensten staan en wie toegang krijgt. Voor een .nl-domein benadrukt SIDN het belang van de juiste domeinnaamhouder: die registratie is relevant wanneer je wijzigingen of een verhuizing wilt regelen.

Bespreek daarnaast wat je aan het einde van de samenwerking kunt meenemen. Denk aan teksten, beelden, ontwerpbestanden, broncode, instellingen en documentatie. Vraag welke gebruiksrechten en licenties daarbij horen. Leg onduidelijkheden vast in de overeenkomst; ga niet uit van de veronderstelling dat betaling automatisch iedere denkbare overdracht omvat.

Laat de aanbieder één praktisch vertrekscenario uitleggen: wat gebeurt er als een ander bureau het beheer overneemt? Wat wordt geleverd, welke hulp is nodig en welke kosten kunnen daarbij ontstaan? Een helder antwoord hoeft niet te betekenen dat elke techniek zonder werk uitwisselbaar is. Het betekent dat de afhankelijkheid vooraf zichtbaar wordt.

Markeer in je vergelijking wat inbegrepen, uitgesloten, optioneel of nog onbekend is. Laat iedere aanbieder reageren op dezelfde open punten. Het doel is niet om alle voorstellen identiek te maken; het is om te begrijpen waar de verschillen waarde toevoegen of risico verminderen.

Bekijk ook passend werk en bespreek wat de aanbieder daarin heeft gedaan. Een mooi beeld in een portfolio vertelt niet automatisch wie verantwoordelijk was voor inhoud, techniek en onderhoud. Vraag naar de afwegingen achter een project dat op jouw situatie lijkt, zonder resultaten van een andere organisatie als voorspelling voor jouw website te behandelen.

Twijfel je nog over de bouwroute, lees dan eerst zelf bouwen, template of maatwerk. Zoek je hulp bij het afbakenen van een nieuwe website, dan vind je onze aanpak bij een website laten maken. Neem de opdrachtomschrijving en je belangrijkste open vragen mee wanneer je je vraagstuk bespreekt.