Maatwerk SaaS laten bouwen: kosten, doorlooptijd en valkuilen

Begin met een eerste versie die klein genoeg is

De meeste SaaS-ideeën beginnen te groot. Logisch: je ziet het eindplaatje al voor je. Maar elke functie die je toevoegt, moet gebouwd, getest en onderhouden worden, en schuift de dag op waarop je van echte gebruikers leert of je idee werkt.

Eric Ries, die de term minimum viable product (MVP) bekend maakte, omschrijft het als de versie van een product waarmee je met zo min mogelijk moeite zoveel mogelijk leert over je klanten. Hij benadrukt zelf dat het niet gaat om een uitgekleed product, maar om leren. Voor een SaaS betekent dat: één soort gebruiker, één belangrijk probleem, en dat probleem goed oplossen.

In een eerste versie horen het hoofdproces, inloggen, een eenvoudige manier om gegevens te beheren en een goede basis voor beveiliging. De lijst hieronder kan bijna altijd wachten.

• Meerdere soorten gebruikers met elk hun eigen rechten.
• Uitgebreide dashboards en rapportages.
• Koppelingen die je de eerste maanden ook met de hand kunt doen, zoals een export naar je boekhouding.
• Meerdere talen, tenzij je klanten die echt nodig hebben.
• Instellingen voor elke denkbare uitzondering.

Wat bepaalt de kosten?

Een prijs voor maatwerk hangt minder af van hoeveel schermen je app heeft dan van wat er achter die schermen gebeurt. Dit zijn de onderdelen die de rekening het meest bepalen.

Een handige oefening: schrijf voor elk onderdeel op waarom je het in de eerste versie nodig hebt. Kun je dat niet in één zin uitleggen, dan is het een kandidaat voor later.

Functies

Het aantal dingen dat je app kan, en vooral hoeveel regels en uitzonderingen erachter zitten.

Gebruikersrollen

Elke rol, zoals beheerder, medewerker of klant, betekent eigen rechten die gebouwd en getest moeten worden.

Koppelingen

Elke verbinding met een ander systeem, zoals een boekhoudpakket, CRM of externe API, kost bouwtijd en later onderhoud.

Betalingen

Abonnementen, facturen, proefperiodes en mislukte betalingen netjes afhandelen is meer werk dan het lijkt.

Beheerschermen

De schermen waarmee jij klanten, accounts en instellingen beheert. Vaak vergeten, maar je gebruikt ze elke dag.

Beveiliging en privacy

Bewaar je persoonsgegevens, dan moeten toegang, opslag en logging daarop zijn ingericht.

Vaste prijs of per uur?

Bij een vaste prijs weet je vooraf wat je betaalt. Dat werkt als helder is wat er gebouwd wordt. Daarom begint een goed traject met het opschrijven van de scope: wat er wel in zit, en net zo belangrijk, wat niet. Wil je onderweg iets toevoegen, dan spreek je daar een nieuwe prijs voor af, in plaats van dat de rekening ongemerkt oploopt.

Per uur betalen is flexibeler, maar het risico ligt bij jou: duurt iets langer, dan betaal je meer. Dat past bij werk waarvan je vooraf echt niet weet hoe het uitpakt, zoals onderzoek naar een koppeling met een systeem zonder goede documentatie.

Voor nieuwe SaaS en webapps werk ik met een vaste prijs per project. Projecten beginnen bij €5.000 exclusief btw. Bij een groter idee is het vaak slim om in fases te werken: een vaste prijs voor de eerste versie, en pas daarna de volgende stap prijzen, op basis van wat je van je gebruikers hebt geleerd.

Zo verloopt een goed traject

Elk project is anders, maar een goed traject heeft bijna altijd dezelfde stappen. Het belangrijkste is dat je onderweg regelmatig iets werkends ziet, zodat je kunt bijsturen voordat er weken werk de verkeerde kant op gaan.

1. 1Kennismaking: je vertelt wat je wilt oplossen en voor wie.
2. 2Scope op papier: wat er in de eerste versie zit en wat niet.
3. 3Een vaste offerte op basis van die scope.
4. 4Bouwen in korte rondes, met na elke ronde een demo die je zelf kunt uitproberen.
5. 5Testen met een paar echte gebruikers voordat iedereen erbij mag.
6. 6Lancering: live zetten, met monitoring en back-ups vanaf dag één.
7. 7Onderhoud: updates, bugs oplossen en verder bouwen op wat gebruikers vragen.

Hoe lang duurt het?

Eerlijk antwoord: dat hangt af van alles hierboven. Een eenvoudige webapp voor intern gebruik is vaak een kwestie van weken, een SaaS met betalingen, meerdere rollen en koppelingen eerder van maanden. Wie je een doorlooptijd belooft voordat de scope op papier staat, gokt.

Projecten lopen zelden uit door het programmeren alleen. Vaker zit de vertraging in wachten: op feedback, op teksten en content, op toegang tot een extern systeem of op de goedkeuring van een betaalprovider. Plan die dingen vroeg in, dan voorkom je dat je developer stilstaat.

De grootste vertrager is een scope die onderweg groeit. Uit het Pulse of the Profession-onderzoek van PMI uit 2018 bleek dat 52 procent van de afgeronde projecten te maken had met scope creep of ongecontroleerde wijzigingen in de scope. Nieuwe ideeën zijn prima, maar zet ze op een lijst voor de volgende versie.

De valkuilen die je geld kosten

De meeste problemen met maatwerk zie je pas na de lancering, als het te laat is om ze goedkoop op te lossen. Deze vijf kom ik het vaakst tegen.

Vooral het tweede punt wordt vaak over het hoofd gezien. In Nederland blijft het auteursrecht op software bij de maker, tenzij het met een schriftelijke akte wordt overgedragen. Dat je voor het werk betaalt, regelt dus niet vanzelf wat je met de code mag. Leg het daarom vooraf vast, samen met waar de broncode staat en hoe je erbij kunt.

• Een scope die onderweg blijft groeien, zonder dat iemand de prijs of planning aanpast.
• Geen duidelijke afspraken over de code en de accounts. Maak schriftelijke afspraken over eigendom en gebruiksrechten van de code, en zorg dat je toegang hebt tot de broncode. Zet accounts zoals je domein, hosting, database en betaalprovider op naam van je eigen bedrijf.
• Vastzitten aan één partij, bijvoorbeeld door een gesloten platform of zeldzame technologie die alleen je huidige developer kent.
• Geen budget voor onderhoud. Na de lancering begint het werk pas: updates, bugs en wensen van je eerste klanten.
• Beveiliging overslaan om sneller live te kunnen. De OWASP Top 10 is een goede ondergrens voor wat in orde moet zijn voordat je echte klantgegevens opslaat.

Kies voor bewezen technologie

Het is verleidelijk om een SaaS te bouwen met het nieuwste framework. Developer Dan McKinley schreef er een bekend essay over, Choose Boring Technology: van technologie die al jaren meegaat weet je wat ze wel en niet kan, en de problemen zijn al eens opgelost en beschreven. Bij nieuwe technologie ontdek je die problemen zelf, op jouw kosten.

Daarom bouw ik met Java, Spring Boot, PostgreSQL en Vue. Het is de technologie waarmee ik ook bij grote organisaties als ING en ABN AMRO werk. Het is breed gebruikt, wordt lang ondersteund en er zijn veel developers die ermee overweg kunnen. Dat laatste is belangrijk: je wilt niet afhankelijk zijn van één persoon, ook niet van mij.

Wat ik niet bouw: mobiele apps en desktop-apps. Een goede webapp werkt wel gewoon op je telefoon, in de browser.

Voorbeeld: Traecy

Traecy is mijn eigen SaaS, die ik sinds 2025 bouw. Het helpt kwaliteitsmanagers in de voedselsector: Traecy filtert RASFF-meldingen, de Europese waarschuwingen over risico’s in voedsel en diervoeder, per grondstof, vraagt documenten op bij leveranciers en legt in een audit-trail vast wie wat deed.

Het begon met één vraag uit de praktijk: hoe weet een kwaliteitsmanager op tijd welke RASFF-melding over de eigen grondstoffen gaat, zonder er elke ochtend zelf naar te zoeken? Pas toen dat werkte, kwamen de verzoeken aan leveranciers en de audit-trail erbij. Inmiddels werken 7 bedrijven uit de voedselsector ermee, zoals Willemsen Kip, TM Salades en Habo Vlees.

Traecy draait op dezelfde technologie die ik voor klanten gebruik: Java en Spring Boot, PostgreSQL en Vue. Het laat zien hoe ik werk: klein beginnen, leren van echte gebruikers en daarna pas uitbreiden.