Voor je een software-offerte tekent: 11 dingen die erin moeten staan

Een software-offerte ziet er meestal redelijk uit. Mooie indeling, een totaalbedrag, een planning en een uitleg van wat er gaat gebeuren. De founder leest het, hoort de prijs, voelt aan dat het wel binnen budget past en is geneigd te tekenen.

Een offerte zonder scope, aannames, verantwoordelijkheden en risico’s lijkt duidelijker dan hij is. Wat erín staat, wordt vaak overschat. Wat eruít is gelaten, kost je later het meeste.

Hieronder elf onderdelen die ik in elke offerte expliciet wil zien voor er getekend wordt. Niet om bureaus te wantrouwen, maar om de afspraken die anders ongeschreven blijven zichtbaar te maken.

1. Scope, wat wordt er precies gebouwd

Vraag om concrete functionele beschrijvingen. Niet “een dashboard”, maar “een dashboard met deze drie schermen, deze vier acties en deze twee filters”. Een offerte die alleen werkpakketten en uren noemt, geeft je geen meetbare beoordeling van wat je krijgt.

Zonder concrete scope schuift een planning ongemerkt mee met de interpretatie van twee partijen.

2. Aannames

Iedere offerte rust op aannames. Bijvoorbeeld dat klanten al een account bij een derde partij hebben, dat data in een bepaald formaat aangeleverd wordt, dat één designsysteem voldoende is of dat het team Nederlands spreekt.

Die aannames moeten erin staan. Niet om de bouwer te ontslaan van verantwoordelijkheid, maar omdat ze de basis vormen waarop het bedrag berekend is. Als één van die aannames niet klopt, hoort het gesprek opnieuw te beginnen.

3. Wat expliciet niet inbegrepen is

Dit is misschien wel het belangrijkste deel. Een offerte beschrijft graag wat er gebouwd wordt. Wat er níet inbegrepen is, daar zitten de verrassingen.

Vraag specifiek: zit hosting erin? Domeinregistratie? E-mailverkeer voor de applicatie? Een testomgeving? Een eerste analytics-koppeling? Toegankelijkheidstoetsing? Translation? Browsercompatibiliteit voor oudere apparaten? Een staging-omgeving voor je eigen team?

Als deze dingen niet expliciet erin staan, hoor je later: “Dat hoorde niet bij de offerte.”

4. Planning

Een planning zonder mijlpalen is geen planning. Wat is het eerste bruikbare moment? Wanneer wordt welke functionaliteit opgeleverd? Wanneer is er een testperiode en hoe lang?

Geef de voorkeur aan een planning die aan beslissingen gekoppeld is, niet alleen aan technische mijlpalen. “Backend klaar” zegt jou als founder weinig. “Eerste klant kan zich registreren en zijn eerste actie uitvoeren” zegt veel.

5. Eigendom van code

Zonder expliciete clausule is de eigendomsvraag in Nederland niet automatisch geregeld zoals founders denken. Vraag om een duidelijke regel: jij wordt eigenaar van de code, de designs, de documentatie, de accounts en de infrastructuur die op naam van het bureau staan.

Vraag specifiek of het bureau open source-componenten of eigen frameworks gebruikt waarvoor licentievoorwaarden gelden. Die voorwaarden moeten je niet later beperken.

6. Afhankelijkheden

Welke externe diensten worden gebruikt voor authenticatie, betalingen, mail, monitoring, hosting? Welke kosten brengen die mee? Welke afhankelijkheid creëert dat?

Een softwarebureau kiest soms voor diensten waarvan de prijs of betrouwbaarheid niet bij jouw fase past. Vraag erom voor de keuzes gemaakt zijn, niet erna.

7. Onderhoud

Wat gebeurt er na oplevering? Wie host het? Wie krijgt meldingen als er iets misgaat? Wat doet het bureau bij bugs in de eerste maanden? Vanaf wanneer rekent het uren?

Veel founders ontdekken pas na oplevering dat onderhoud niet inbegrepen is, dat support buiten kantooruren extra kost, of dat er per maand een vast bedrag verwacht wordt. Liever vooraf bespreken.

8. Testwerk

Wie test wat? Wordt er automatisch getest, handmatig getest, of allebei? Wie meldt bugs en wie lost ze op binnen welk tijdsbestek?

Een offerte zonder expliciet testbudget verschuift dat werk meestal naar oplevering, waar de druk om “live te gaan” het wint van zorgvuldigheid.

9. Security

Wat doet het bureau aan basics: HTTPS, secure-by-default headers, wachtwoordbeleid, backups, toegangscontrole tot de productieomgeving? Welke gevoelige data slaan jullie op en hoe?

Voor een vroege startup hoeft dit geen security-audit te zijn. Het moet wel een aantoonbare set basismaatregelen zijn, niet “we doen dat netjes”.

10. Acceptatiecriteria

Wanneer is iets klaar? Wat moet er waar zijn voordat jij accepteert? Een offerte zonder acceptatiecriteria geeft het bureau het recht om zelf te bepalen wat “opgeleverd” betekent.

Schrijf voor de belangrijkste features expliciet op wat je accepteert. Bijvoorbeeld: “een nieuwe klant kan binnen 3 minuten een account aanmaken en hun eerste actie uitvoeren op zowel mobiel als desktop”.

11. Wijzigingsverzoeken

Wijzigingen komen altijd. Hoe worden ze afgehandeld? Wie schat ze in? Welke wijzigingen vallen binnen de offerte en welke worden apart afgerekend?

Een redelijke aanpak: kleine wijzigingen binnen de scope worden geabsorbeerd, grotere wijzigingen krijgen een eigen kleine offerte met inschatting. Geen onbeperkte wijzigingen “binnen redelijk gebruik”, dat creëert ruzie achteraf.

Waarom totaalprijs bijna niets zegt zonder context

Twee offertes met hetzelfde bedrag kunnen totaal verschillende waarde leveren. Eén bouwt drie functies met aandacht voor testwerk, security en onderhoud. De ander bouwt zes functies waarvan de helft niet getest is en die je over zes maanden moet vervangen.

Voor een founder die voor het eerst een softwarebureau inschakelt, is een offerte beoordelen lastig. Het is geen onkunde, het is gebrek aan vergelijkingsmateriaal. Andere founders die dit pad hebben gelopen, herkennen patronen die jij voor het eerst ziet.

Een snelle onafhankelijke check van een bestaande offerte helpt vaak meer dan een week extra zelf zitten lezen.

---

Sta je voor deze beslissing?

Stuur me kort de context of plan een gratis gesprek. Dan kijken we samen wat de meest verstandige volgende stap is voor je tijd, geld of focus vastlegt.

Plan een gratis gesprek → · Mail direct: hello@yourstartup.expert