Webapp, SaaS of maatwerk: welke route past?

Een webapp, SaaS en een custom platform zijn geen drie elkaar uitsluitende productsoorten. Een webapp beschrijft hoe je software gebruikt, SaaS hoe die als dienst wordt geleverd en maatwerk voor welke behoefte de software wordt gebouwd. Een zelf ontwikkeld platform kan dus tegelijk een webapp én een SaaS-product zijn. De nuttige keuze is of je bestaande software afneemt, die aanvult of zelf iets laat bouwen. Onze gids voor maatwerksoftware behandelt het bouwtraject; hier vergelijken we die routes.

Bronnen gecontroleerd in september 2026. Controleer de actuele voorwaarden van de dienst die je overweegt.

Welke vraag beantwoordt iedere term?

Een webapp gebruik je via een browser. Dat zegt niets over een maximumaantal gebruikers of over hoe ingewikkeld de toepassing is. AWS noemt bij webapps zowel samenwerkingstoepassingen als webwinkels en online bankieren. Het browservenster maakt een toepassing niet automatisch klein of alleen intern bruikbaar.

SaaS staat voor Software as a Service. Je gebruikt software die een aanbieder als dienst beschikbaar stelt en beheert. Een abonnement of betaling naar gebruik is gebruikelijk, zoals AWS bij het SaaS-model beschrijft. SaaS afnemen voor je eigen bedrijf en een SaaS-product laten bouwen om zelf aan te bieden zijn twee verschillende beslissingen.

“Custom platform” is ook geen vaste technische categorie. Vraag welke taken, gebruikers en systemen ermee worden bedoeld. Een platform kan intern werk ondersteunen, klanten toegang geven of als product worden aangeboden. Het woord vertelt nog niet wie de code mag wijzigen of wie storingen oplost.

Welke routes kun je werkelijk vergelijken?

Begin met de uitkomst die je nodig hebt. Wil je medewerkers een offerte laten afhandelen, of wil je software verkopen waarmee andere bedrijven hun offertes maken? De schermen kunnen op elkaar lijken. De verantwoordelijkheden verschillen.

Route	Wat neem je af of bouw je?	Wat moet je onderzoeken?
Bestaande SaaS gebruiken	Toegang tot een beheerd product	Past het proces binnen functies, instellingen en voorwaarden?
Bestaande software aanvullen	Een koppeling of afgebakende extra toepassing	Welke taak ontbreekt en welk systeem blijft leidend?
Maatwerk voor eigen gebruik bouwen	Software voor jouw afgesproken werkproces	Wie bepaalt de scope en regelt ontwikkeling, beheer en overdracht?
Een eigen SaaS-product aanbieden	Een dienst voor externe klanten	Welk terugkerend probleem los je op en hoe lever je de dienst doorlopend?

Deze routes kunnen naast elkaar bestaan. Je kunt een eigen klantportaal bouwen en de boekhouding als SaaS afnemen. Ook een SaaS-aanbieder kan externe diensten gebruiken voor onderdelen van zijn product. Beoordeel de grenzen tussen die onderdelen in plaats van één label voor je hele bedrijf te kiezen.

Wanneer past een bestaand pakket?

Een bestaand pakket is een kandidaat als jouw team het benodigde proces ermee kan uitvoeren en je de product- en beheerafspraken kunt accepteren. Laat een gewone taak én een uitzondering zien. Bij een offerteproces kan dat een gewijzigde prijs zijn nadat een voorstel al is goedgekeurd.

Vraag hoe ver instellingen en beschikbare modules je brengen. Een afwijkende werkwijze hoeft geen reden voor maatwerk te zijn; soms is aanpassen aan het pakket verstandig. Maar maak het resterende handwerk zichtbaar. Als iemand na iedere goedkeuring gegevens naar verschillende bestanden moet kopiëren, hoort dat bij de vergelijking.

Kijk verder dan de demonstratie. Welke toegang krijgt een nieuwe medewerker? Wat verandert als je een module opzegt? Welke gegevens kun je exporteren en wat blijft alleen binnen het product bruikbaar? Dat zijn vragen voor de concrete dienst en overeenkomst, niet voor SaaS in het algemeen.

Een lage abonnementsprijs maakt een pakket niet vanzelf passend. Een omvangrijk voorstel voor eigen ontwikkeling bewijst evenmin dat je dat nodig hebt. De vergelijking van AFAS en maatwerk laat zien hoe je inrichting en een aanvulling eerst kunt onderzoeken.

Wanneer is een aanvulling genoeg?

Als het bestaande pakket de kern goed ondersteunt en één afgebakende taak ontbreekt. Misschien moeten klanten een aanvraag kunnen aanvullen zonder toegang tot de interne administratie. Dan kan een apart scherm nuttig zijn, terwijl prijsafspraken en facturatie in het bestaande systeem blijven.

Maak de grens expliciet. Welke gegevens leest de aanvulling, wat mag zij wijzigen en waar wordt een aanvraag definitief? Een API biedt alleen mogelijkheden die de leverancier daadwerkelijk beschikbaar stelt. Laat de benodigde handelingen aantonen, inclusief een fout of correctie. Onze uitleg over software koppelen gaat daarop in.

Wanneer kies je voor maatwerk voor je eigen bedrijf?

Wanneer je een concrete taak wilt ondersteunen die na het beoordelen van bestaande opties onvoldoende past. Leg uit wat gebruikers moeten kunnen afronden en welke uitzondering nu niet goed wordt verwerkt. “Ons bedrijf is uniek” is daarvoor te breed.

Gebruik een denkbeeldig offerteproces. Medewerkers combineren gegevens uit bestaande systemen, passen een afgesproken berekening toe en laten een bevoegde collega een afwijking goedkeuren. De aanvraag is pas bruikbaar als ook een afwijzing, ontbrekende invoer en een latere correctie worden verwerkt. Dat kan een afgebakende maatwerkopdracht zijn, zonder de hele bedrijfsadministratie te vervangen.

Maatwerk geeft ruimte om de werking op de opdracht af te stemmen. Daar horen keuzes en beheer bij. Wie bepaalt welke wens voorrang krijgt? Wie controleert een gewijzigde rekenregel? En wie blijft verantwoordelijk als de oorspronkelijke opdrachtgever binnen jouw bedrijf vertrekt?

Vraag ook welke onderdelen op bestaande diensten of bibliotheken leunen. Maatwerk betekent niet dat alles opnieuw wordt ontwikkeld. Het betekent evenmin dat er na de oplevering geen abonnementen of leveranciersafhankelijkheden meer zijn.

Wat verandert als je zelf SaaS gaat aanbieden?

Dan lever je een doorlopende dienst aan andere organisaties of gebruikers. Je moet begrijpen welk probleem ze ermee oplossen, wie besluit over de aanschaf en waarom ze blijven gebruiken. Een interne toepassing die voor jouw team werkt, beantwoordt die vragen nog niet.

Onderzoek de gewenste werkwijze met beoogde klanten. Laat hen een representatieve taak uitvoeren en bespreek wat ingebruikname vraagt. Daar is geen algemeen minimumaantal betalende klanten of vast omzetbedrag voor dat ieder idee bewijst. Beschrijf welk bewijs jij nodig hebt om de volgende investering te verantwoorden.

Naast de kernfunctie komen werkzaamheden zoals klanten aansluiten, toegang beheren, wijzigingen uitbrengen, ondersteuning en beëindiging van gebruik. Niet iedere dienst vraagt zelfregistratie of automatische abonnementsbetaling. Een aanbieder kan ook klanten begeleid aansluiten en op factuur werken. Kies de werkwijze die je wilt leveren en neem het bijbehorende werk mee in de begroting.

Bekijk ook wat er gebeurt als klanten verschillende wensen hebben. Kun je met instellingen werken of ontstaan aparte productvarianten? Spreek af wie daarover beslist en hoe wijzigingen worden getest. Een extra klant is pas geholpen als je de toegezegde dienst ook kunt blijven beheren.

Moet SaaS altijd één gedeelde database gebruiken?

Nee. AWS onderscheidt voor SaaS gedeelde middelen, aparte middelen per klant en mengvormen. Ook bij aparte middelen kan de aanbieder klanten vanuit een gemeenschappelijke beheer- en leveringsaanpak bedienen. Het aantal databases bepaalt dus niet of je software als dienst aanbiedt.

De keuze hoort bij je eisen en beheer, niet bij een willekeurige gebruikersgrens. Laat uitleggen hoe toegang tot klantgegevens wordt begrensd en hoe updates, herstel en capaciteitsproblemen worden afgehandeld. Een aparte database vervangt geen controle op wie een bestand of rapport mag opvragen.

Een klantnummer toevoegen is evenmin een complete scheiding. Vraag de ontwikkelaar om te laten zien dat een gebruiker geen gegevens van een andere klant kan lezen of wijzigen, ook buiten de gewone schermroute. Laat de benodigde controles afleiden uit de toepassing, zonder vooraf één databasepatroon als standaardantwoord vast te leggen.

Wie regelt onderhoud, toegang en overdracht?

Bij SaaS neemt de aanbieder beheer van de aangeboden dienst op zich, maar jouw organisatie houdt eigen taken. Microsofts uitleg over gedeelde verantwoordelijkheid maakt onder meer gegevens, instellingen en gebruikersbeheer zichtbaar. Leg voor jouw dienst vast wie accounts intrekt, fouten onderzoekt en wijzigingen controleert.

Bij eigen software kun je het technische beheer uitbesteden. Dan wil je dezelfde duidelijkheid over updates, bereikbaarheid en herstel. Zelf laten bouwen betekent niet dat je eigen medewerkers servers moeten beheren; een beheercontract betekent niet dat alle toekomstige veranderingen zijn inbegrepen.

Leg per onderdeel vast welke rechten en materialen je krijgt. Vraag naar bronbestanden, documentatie, instellingen en afhankelijkheden, en laat een overdracht oefenen. De uitleg over code-eigendom werkt dat uit. Eigendom, een gebruikslicentie en de mogelijkheid om de software praktisch elders te draaien zijn verschillende vragen.

Controleer daarnaast een gegevensexport met echte relaties en bijlagen. Alleen een downloadknop zien is niet genoeg om te weten of een opvolger verder kan met het resultaat. Dat geldt bij een SaaS-pakket én bij een eigen toepassing.

Hoe vergelijk je kosten en doorlooptijd eerlijk?

Gebruik dezelfde taak, hoeveelheid gegevens en verwachtingen voor beheer. Zet eenmalige en terugkerende werkzaamheden apart: selectie, inrichting of bouw, migratie, koppelingen, opleiding en het gebruik na de start. Neem ook de tijd van je eigen mensen mee.

Bij een SaaS-pakket kunnen gebruikers, modules of gebruikseenheden de rekening beïnvloeden. Bij eigen software spelen scope, bestaande gegevens en afhankelijkheden mee. Wie zelf SaaS aanbiedt, moet ook de levering aan klanten begroten. Geen van die routes heeft alleen op basis van het label een vaste prijs of terugverdientijd.

Vraag een planning met benoemde aannames en beslismomenten. Wat kan beginnen, wat wacht op toegang tot een bron en welke proef kan de scope nog veranderen? Een pakket kan invoeringswerk vragen; een afgebakende eigen toepassing kan kleiner zijn dan het woord “platform” doet vermoeden. De gids voor softwarekosten helpt om voorstellen op dezelfde onderdelen te vergelijken.

Hoe begin je concreet?

Schrijf op wie de software gaat gebruiken en welke taak die persoon moet kunnen afronden. Maak daarna onderscheid tussen een oplossing voor je eigen bedrijf en een dienst die je aan externe klanten wilt leveren. Dat bepaalt welke vragen je eerst moet beantwoorden.

Laat bestaande software en een voorstel voor maatwerk software laten maken hetzelfde voorbeeld afhandelen. Vergelijk wat overblijft aan handwerk, beheer en afhankelijkheden voordat je beslist hoeveel je zelf bouwt.

Wil je die routes samen beoordelen? Plan een gesprek en neem je proces en huidige systemen mee.