In het kort
Een webapplicatie laten maken begint met de vraag welk werk mensen erin moeten doen, niet met schermen of techniek. Leg vast welk probleem de webapp oplost, wie hem gebruikt, welke handelingen en gegevens nodig zijn en wat er in de eerste versie zit. Kies daarna pas tussen een website, een standaardpakket of een webapplicatie op maat. Met een ingevulde projectkaart krijg je offertes die je kunt vergelijken en een eerste versie die snel bruikbaar is.
Wat is een webapplicatie?
Een webapplicatie is software die in de browser draait. Je installeert niets: gebruikers gaan naar een adres, loggen in en doen hun werk. Het verschil met een website zit in wat de bezoeker doet. Een website informeert: je leest over diensten, prijzen of een bedrijf. In een webapplicatie voer je gegevens in, wijzig je ze en handel je taken af. Een klantportaal, een planningsscherm, een offertetool en een werkbonnensysteem zijn allemaal webapplicaties.
Een webapp laten maken heeft praktische voordelen. Hij werkt op elke computer en telefoon met een moderne browser, updates staan direct voor iedereen klaar en je hoeft niet via een appwinkel. Wil je dat gebruikers de webapplicatie ook als app op hun startscherm zetten of beperkt offline gebruiken, dan kan dat met de technieken van een progressive web app. Die zijn volgens MDN gewoon webapplicaties met extra mogelijkheden, geen apart soort software.
Een webapplicatie laten maken is zinvol wanneer een proces nu op losse rekenbladen, mail en telefoontjes draait en daardoor fouten of vertraging oplevert. Denk aan opdrachten die worden overgetypt, klanten die bellen om een status te vragen of medewerkers die niet weten wie een klus heeft opgepakt.
Website, standaardpakket of webapplicatie op maat?
Twee vragen bepalen de route. De eerste: moeten gebruikers alleen informatie lezen, of ook werk doen? Gaat het alleen om informatie, een aanvraagformulier en vindbaarheid, dan heb je een goede website nodig en geen webapplicatie. Een formulier dat een aanvraag in je CRM zet, maakt een website nog geen webapp.
De tweede vraag: dekt een bestaand pakket het werkproces? Voor boekhouding, standaard CRM, roosters en webshops bestaan prima pakketten. Past zo’n pakket voor het grootste deel en kun je de rest met instellingen of een koppeling oplossen, dan is dat bijna altijd sneller en goedkoper dan iets nieuws laten bouwen.
Een webapplicatie op maat past wanneer je werkwijze afwijkt van wat pakketten bieden en die afwijking juist je voordeel is, of wanneer medewerkers nu dagelijks tussen drie systemen schakelen. Ook dan hoeft niet alles maatwerk te zijn: vaak koppelt de webapp aan je bestaande boekhouding of CRM en bouw je alleen het stuk dat ontbreekt. De afweging tussen maatwerk en standaard lees je uitgebreider in de uitleg over wat bedrijfssoftware op maat is.
Sjabloon: de projectkaart voor je webapplicatie
Vat het idee samen op één pagina voordat iemand gaat bouwen of offreren. Een bruikbare projectkaart heeft acht velden. Probleem: wat gaat er nu mis en wat kost dat? Gebruikers en rollen: wie werkt ermee en wat mag ieder zien of doen? Kernhandelingen: welke vijf tot tien dingen moet je in de webapp kunnen doen? Gegevens: welke informatie wordt vastgelegd en wie is eigenaar? Koppelingen: met welke systemen wisselt de webapp gegevens uit? Eerste versie: wat moet er op de eerste werkdag zijn? Bewust later: wat schuif je op? Succesmaat: waaraan zie je na drie maanden dat het werkt?
Neem als fictief voorbeeld een onderhoudsbedrijf met twaalf monteurs. Het probleem: werkbonnen worden op papier ingevuld en op kantoor overgetypt, waardoor facturen pas dagen later de deur uitgaan. Gebruikers zijn de planner, de monteurs en later misschien klanten. Kernhandelingen: opdracht aanmaken, monteur toewijzen, werkbon op de telefoon invullen, foto toevoegen, laten aftekenen en doorzetten naar facturatie. Koppeling: de boekhouding. Bewust later: een klantomgeving. Succesmaat: een factuur binnen één werkdag na afronding.
De kaart dwingt keuzes af die anders pas tijdens de bouw opduiken. Moet een monteur ook offline een werkbon kunnen invullen in een kelder zonder bereik? Mag een planner een afgetekende werkbon nog wijzigen? Wie lost het op als de boekhouding een factuur weigert? Zulke vragen beantwoord je liever aan tafel dan in een derde bouwronde.
Rekenvoorbeeld: waarom een kleinere eerste versie loont
Stel dat het onderhoudsbedrijf alles in één keer wil: drie rollen (planner, monteur, klant), negen schermen en twee koppelingen (boekhouding en agenda). Een leverancier rekent in dit fictieve voorbeeld gemiddeld twee dagen per scherm, twee dagen per rol met eigen rechten en vier dagen per koppeling, plus dertig procent voor ontwerp, testen en livegang. Dat is 9 × 2 + 3 × 2 + 2 × 4 = 32 dagen, maal 1,3 is afgerond 42 bouwdagen.
Nu de eerste versie zonder klantrol en zonder agendakoppeling. Er blijven zes schermen, twee rollen en één koppeling over: 6 × 2 + 2 × 2 + 1 × 4 = 20 dagen, maal 1,3 is 26 bouwdagen. Dat scheelt zestien dagen, bijna veertig procent. Belangrijker nog: monteurs werken weken eerder met de webapp, en wat je daarvan leert, bepaalt of de klantomgeving later echt nodig is en hoe die eruit moet zien.
De getallen zijn bedacht om de rekensom te tonen, geen prijzen of doorlooptijden van Softora of een andere partij. Het patroon is wel herkenbaar: rollen en koppelingen voegen meer werk toe dan je zou denken, omdat elk daarvan rechten, foutafhandeling en testwerk meebrengt. Schrap daarom eerst daar, niet in de kernhandelingen.
Hoe verloopt het ontwikkelen van een webapplicatie?
Een webapplicatie laten ontwikkelen gaat het best in zes stappen. Eén: de projectkaart en een gesprek met de mensen die ermee gaan werken. Twee: een functioneel ontwerp waarin per handeling staat wat er gebeurt, inclusief uitzonderingen. Drie: een klikbaar prototype waarmee gebruikers de belangrijkste schermen proberen voordat er gebouwd wordt.
Het GOV.UK Service Manual beschrijft dat idee voor overheidsdiensten: probeer in een vroege fase met prototypes verschillende oplossingen uit, test vooral de riskantste aannames en verwacht dat je een deel van die ideeën weggooit. Dat is goedkoper dan ontdekken dat een gebouwd scherm niet werkt.
Vier: bouwen in korte rondes van een paar weken, met na elke ronde iets wat gebruikers echt kunnen proberen. Vijf: een acceptatietest met vooraf opgeschreven scenario’s, ook voor foutgevallen zoals een monteur zonder bereik of een geweigerde factuur. Zes: livegang met afspraken over beheer, back-ups, updates en wie je belt als er iets misgaat. Hoe je die test opzet, lees je in het stappenplan voor een acceptatietest van software.
Waar let je op bij beveiliging, toegankelijkheid en eigendom?
Een webapplicatie bevat vaak klantgegevens, prijzen of persoonsgegevens van medewerkers, en staat bereikbaar op internet. Vraag een leverancier daarom hoe inloggen, rechten per rol, wachtwoordherstel en het bijhouden van wijzigingen geregeld zijn. De OWASP Application Security Verification Standard is een openbare lijst met beveiligingseisen voor webapplicaties. Je hoeft die niet zelf te kennen, maar een leverancier moet kunnen uitleggen welk niveau hij aanhoudt en hoe hij dat test.
Gebruiken consumenten de webapplicatie, bijvoorbeeld als klantportaal of boekingsmodule, controleer dan of de toegankelijkheidsregels die sinds 28 juni 2025 gelden op jouw bedrijf van toepassing zijn. De ACM houdt daar toezicht op. Ook als de regels niet voor je gelden, is een webapp die met toetsenbord en schermlezer werkt prettiger voor iedereen.
Leg tot slot vast wie eigenaar is van de broncode en de gegevens, waar de webapplicatie draait en hoe je kunt overstappen als de samenwerking stopt. Vraag of je een export van alle gegevens kunt krijgen en of de code in een omgeving staat waar jij toegang toe hebt. Dat zijn geen wantrouwige vragen, maar gewone afspraken bij software waar je bedrijf op draait.
Wat bepaalt de kosten van een webapplicatie laten maken?
De kosten hangen vooral af van het aantal rollen, kernhandelingen, koppelingen en uitzonderingen, en minder van het uiterlijk. Een webapp met één soort gebruiker en geen koppelingen is een ander project dan een systeem met klanten, medewerkers, rechten en drie gekoppelde pakketten. Daarnaast zijn er doorlopende kosten voor hosting, beveiligingsupdates, beheer en kleine wijzigingen. Een uitgebreide uitleg met kostenposten staat in het artikel over de kosten van bedrijfssoftware laten maken.
Koppelingen verdienen extra aandacht in de begroting. Elke koppeling vraagt afspraken over welke gegevens leidend zijn, wat er gebeurt bij een fout en wie het merkt als de verbinding een keer stilvalt. Hoe zo’n API-koppeling werkt en welke vragen je vooraf stelt, lees je in de uitleg over API-koppelingen.
Vergelijk je meerdere offertes, geef dan iedere leverancier dezelfde projectkaart en vraag per onderdeel wat standaard is, wat geconfigureerd wordt en wat maatwerk is. De handleiding voor het beoordelen van een maatwerk software offerte helpt om verschillen in aannames zichtbaar te maken.
Wat neem je mee naar een eerste gesprek?
Neem de ingevulde projectkaart mee, een paar voorbeelden van hoe het werk nu gaat (een rekenblad, een papieren werkbon, een typische mail) en een lijst van systemen die je al gebruikt met de naam van de beheerder. Bedenk ook welke medewerker het prototype mag uitproberen en tijd heeft om feedback te geven. Met dat pakket kan een leverancier binnen één gesprek zeggen welke route past en wat er in een eerste versie kan.
Wil je een webapplicatie laten maken die aansluit op je bestaande systemen, dan begint Softora bij bedrijfssoftware op maat met precies die projectkaart. Samen bepalen we of een standaardpakket volstaat, of een afgebakende webapp op maat de betere keuze is, en wat er in de eerste versie hoort.
Over deze uitleg
Dit artikel is door Softora met hulp van AI opgesteld en gecontroleerd aan de genoemde openbare bronnen. Het onderhoudsbedrijf, de werkbonnen, de dagen en de bedragen in het rekenvoorbeeld zijn fictief en dienen alleen als uitleg. De illustraties zijn eigen vectorbeelden voor dit artikel, met hulp van code gemaakt; het zijn geen schermopnamen of klantresultaten.
