
Op deze pagina
- Wat een maatwerk webapplicatie is en wat niet
- Wanneer je een applicatie nodig hebt en geen website
- Wat een webapplicatie laten maken kost
- Wat de bouw werkelijk bevat
- Hoe lang het duurt en waarom ramingen schuiven
- Waarom standaard-SaaS voor sommige bedrijven tekortschiet
- Hoe je een ontwikkelpartner kiest
- Wat beveiliging en compliance aan de rekening toevoegen
Een maatwerk webapplicatie is software die in de browser draait en gebouwd is rond het proces van één organisatie in plaats van verkocht aan velen. De grens met een website is niet visueel. Een website publiceert informatie; een applicatie houdt toestand vast, handhaaft regels en doet werk: accounts, rechten, records die veranderen en logica die gevolgen heeft als ze fout is.
Dat verschil bepaalt al het overige: de kosten, de planning, de beveiligingsplichten en wie je moet inhuren. Dit artikel laat zien waar de grens werkelijk ligt, wat ontwikkeling in 2026 kost en welke delen van een offerte hout snijden.
Wat een maatwerk webapplicatie is en wat niet
De praktische toets is of het systeem gebruikers heeft die inloggen en gegevens die veranderen door wat zij doen. Een boekingssysteem, een dealerportaal, een intern calculatiehulpmiddel en een schadeproces zijn applicaties. Een bedrijfswebsite met contactformulier is dat niet, hoe netjes ook gebouwd, en dit onderscheid bepaalt meteen de prijsklasse.
Drie dingen scheiden ze technisch. Een applicatie heeft authenticatie en autorisatie, dus ze moet niet alleen weten wie je bent maar ook wat je mag zien. Ze heeft blijvende toestand die meerdere mensen tegelijk wijzigen, wat transacties, conflictafhandeling en auditsporen met zich meebrengt. En ze heeft bedrijfsregels die in code leven in plaats van in een document, en daar gaat het meeste testwerk naartoe.
Geldt geen van de drie, dan kijk je naar een website en hoor je geen applicatieprijzen te betalen.
Wanneer je een applicatie nodig hebt en geen website
De meeste bedrijven komen bij deze vraag via pijn en niet via strategie. Een spreadsheet is het leidende systeem geworden, drie mensen mailen versies rond, en er is al iets duurs misgegaan. Vier patronen komen steeds terug, en elk daarvan is een gegronde reden om een eigen applicatie te overwegen in plaats van door te blijven plakken.
Een spreadsheet stuurt een echt proces. Prijsstelling, toewijzing, planning. Het werkt tot twee mensen tegelijk wijzigen of tot degene die de formules bouwde vertrekt.
Klanten vragen toegang tot hun eigen gegevens. Bestelhistorie, documenten, projectstatus. PDF's mailen schaalt niet, en een portaal is het gebruikelijke antwoord. Onze gids over het klantportaal behandelt precies dat geval.
Tussen twee systemen ontbreekt een werkstroom. Het ERP houdt voorraad bij en het CRM klanten, en een mens tikt er dagelijks tussen over.
Het standaardpakket dekt 70 % van het proces. De overige 30 % is precies waar je marge zit, en geen enkele instelling komt daar.
Wat een webapplicatie laten maken kost
De tarieven van Europese bureaus beginnen per augustus 2026 rond €12.000 voor een werkelijk kleine applicatie en lopen daarna snel op. Anders dan bij een website zegt het aantal schermen niets: de prijs wordt bepaald door het aantal verschillende gebruikersrollen, het aantal externe systemen en of de gegevens gereguleerd zijn.
Een bruikbare vuistregel bij het lezen van offertes is dat de eerste werkende versie ongeveer de helft van het totaal kost. De andere helft is alles wat het houdbaar maakt: foutafhandeling, randgevallen bij rechten, overname van bestaande gegevens en de rapportages die bij de aftrap niemand noemde.
De goedkoopste knop op de prijs zijn rollen, niet functies. Elke extra gebruikerssoort vermenigvuldigt de rechtensituaties die ontworpen, gebouwd en getest moeten worden, en dat gaat sneller dan bij een extra scherm.
Een systeem met één rol en twintig schermen is geregeld goedkoper dan een systeem met vier rollen en acht schermen. Bestaat een rol alleen om een rapport te bekijken, vraag je dan af of een export het eerste jaar volstaat.
Vraag wat er in maand dertien gebeurt
Applicaties worden niet opgeleverd, ze worden beheerd. Hosting, updates van afhankelijkheden, monitoring en een supportroute kosten ruwweg 15 % tot 25 % van de bouw per jaar, en anders dan bij een website legt een storing het werk stil in plaats van er alleen slecht uit te zien. Een offerte zonder die regel is niet vergelijkbaar met een offerte die hem wel heeft.
Wat de bouw werkelijk bevat
Klanten zien de schermen voor zich. De schermen zijn misschien een derde van het werk. Daaronder liggen vier lagen die zelden in een voorstel staan en altijd op de factuur. Wie hun namen kent, leest een begroting een stuk kritischer en ziet snel waar een goedkope offerte dun is.
Datamodel en migratie. De entiteiten bepalen en overzetten wat er al is, meestal een spreadsheet met inconsistente gegevens die eerst opgeschoond moet worden.
Inloggen en rechten. Rollen, sessies, wachtwoordherstel en de matrix van wie wat mag. Kort te beschrijven en lang te testen.
Koppelingen. Elk extern systeem is een eigen project: inloggegevens, aanroeplimieten, foutafhandeling en een plan voor het moment dat de andere kant niet reageert.
Inzicht in het gedrag. Logging, alarmering en een manier om de vraag te beantwoorden wat het systeem dinsdag om 14:20 uur deed.
Testen loopt dwars door alle vier de lagen. De zinvolle vraag is niet of het gelukkige pad werkt, maar wat er gebeurt op de andere: een dubbele verzending, een sessie die halverwege een formulier verloopt, twee mensen op hetzelfde record, een koppeling die zijn tijd overschrijdt.
Hoe lang het duurt en waarom ramingen schuiven
Drie tot zes maanden tot een eerste productieversie is normaal voor een middelgrote applicatie. De planning schuift om redenen die voorspelbaar genoeg zijn om op te plannen, en volgens onze ervaring veroorzaken er twee de meeste schade. Beide zijn goedkoop te ontmantelen vóór ondertekening.
De eerste is analyse via interview in plaats van observatie. Mensen beschrijven het proces dat zij denken te volgen. Het echte proces kent uitzonderingen, en die uitzonderingen zijn de eisen. Een dag meekijken vindt ze; een workshop meestal niet.
De tweede is een koppeling met een systeem zonder eigenaar. De raming gaat ervan uit dat er een API is en dat die gedocumenteerd is. In week zes blijkt het tegendeel, en een gesprek met een leverancier komt op het kritieke pad te staan.
Een technische verkenning van één week voordat de prijs vastligt vangt bijna dit alles af.

Waarom standaard-SaaS voor sommige bedrijven tekortschiet
Kopen wint van bouwen in de meeste gevallen, en elk bureau dat iets anders beweert is aan het verkopen. SaaS wint op prijs, op tijd tot waarde en op het feit dat iemand anders de beveiligingsupdates doet. Er zijn drie situaties waarin dat ophoudt, en die zijn precies te benoemen.
Het proces is het onderscheid. Als hoe jij calculeert, toewijst of prijst de reden is dat klanten voor je kiezen, haalt een pakket dat iedereen gebruikt precies dat voordeel weg.
De prijs per gebruiker groeit voorbij de bouw. Bij 200 gebruikers is €40 per plek per maand zo'n €96.000 per jaar. Een bouw over vijf jaar afgeschreven wordt dan rekenwerk in plaats van ambitie.
De gegevens mogen niet weg. Locatie, bewaartermijnen of sectorregels sluiten soms elk gedeeld platform uit, en AVG-verplichtingen rond verwerking en opslag zijn eenvoudiger te vervullen op infrastructuur die je zelf beheert.
Er is bovendien een tussenweg die te snel wordt afgeschreven: een configureerbaar platform met een dunne eigen laag erbovenop.
Hoe je een ontwikkelpartner kiest
Portfolio's tonen schermen, en dat is juist het deel dat het minst prijsgeeft. Vier vragen scheiden teams die software beheerd hebben van teams die het alleen opgeleverd hebben, en geen ervan is zo technisch dat je er een ontwikkelaar bij nodig hebt.
Laat iets zien dat je nog steeds beheert. Bouwen is makkelijk; drie jaar met een beslissing leven is de vaardigheid.
Wat ging er mis in het vorige project? Een team zonder antwoord heeft te weinig opgeleverd of speelt niet open kaart.
Van wie zijn de code en de infrastructuuraccounts? Het antwoord hoort van jou te zijn, op papier, met toegang tot de repository vanaf dag één.
Wat gebeurt er als we stoppen met samenwerken? Documentatie, overdracht, inloggegevens. Volgens de Stack Overflow Developer Survey staat technische schuld steevast bij de meest genoemde frustraties van professionele ontwikkelaars, en een deel daarvan zijn geërfde systemen die niemand kan uitleggen.
Een vijfde vraag loont wanneer het systeem bedrijfskritisch is: hoe snel reageren jullie als het op vrijdagavond uitvalt, en wat staat daarover in het contract?
Wat beveiliging en compliance aan de rekening toevoegen
Beveiliging is geen functie die je later toevoegt, en het zo behandelen is precies hoe een project van €30.000 een project van €30.000 plus een incident wordt. De basis is niet exotisch, en een bekwaam team levert die zonder dat je erom vraagt.
De OWASP Top 10 is de referentie die de sector daadwerkelijk gebruikt: gebrekkige toegangscontrole, injectie, verkeerde configuratie en de rest. Vraag of jouw bouw die afdekt, en vraag welke tests dat aantonen.
Boven de basis stijgen de kosten met de verplichting. Persoonsgegevens betekenen bewaarregels, export en verwijdering. Betalingen betekenen dat je kaartgegevens helemaal niet hoort op te slaan. Gereguleerde sectoren betekenen auditsporen en bewijs. Reken op 10 % tot 20 % extra waar een van deze speelt.
Eén verplichting wordt makkelijk vergeten omdat ze niet technisch is: iemand moet na de livegang updates blijven doorvoeren. Benoem die persoon of dat contract voordat je tekent.

Op deze pagina
- Wat een maatwerk webapplicatie is en wat niet
- Wanneer je een applicatie nodig hebt en geen website
- Wat een webapplicatie laten maken kost
- Wat de bouw werkelijk bevat
- Hoe lang het duurt en waarom ramingen schuiven
- Waarom standaard-SaaS voor sommige bedrijven tekortschiet
- Hoe je een ontwikkelpartner kiest
- Wat beveiliging en compliance aan de rekening toevoegen



