Wat is een webapplicatie? Uitleg met voorbeelden

Een webapplicatie is software die je in een browser opent en waarmee je werk doet, zoals inloggen, gegevens invoeren en een proces afhandelen. Waar een gewone website vooral informatie laat zien die voor iedereen gelijk is, onthoudt een webapplicatie wie je bent, slaat ze op wat je invult en reageert ze op wat jij doet.

Dat klinkt abstract, maar het is dagelijkse kost. Het online boekhoudpakket, het klantportaal van je energieleverancier en het planbord van je team zijn webapplicaties. In dit artikel leggen we uit hoe ze werken, waar het verschil met een website en een app zit, en laten we vier voorbeelden zien uit projecten die wij zelf hebben gebouwd. Daarna weet je ook wanneer een standaard SaaS-pakket genoeg is en wanneer niet.

Een webapplicatie bestaat uit twee helften die samenwerken. Het ene deel draait in de browser van de gebruiker en toont de schermen, knoppen en formulieren. Het andere deel draait op een server en doet het eigenlijke werk, zoals regels toepassen, gegevens opslaan, rechten controleren en met andere systemen praten. De gebruiker hoeft niets te installeren, want de browser haalt de applicatie elke keer op bij de server.

Een bruikbare toets is deze. Kan een bezoeker iets aanmaken, wijzigen of afronden dat bij hem of haar hoort, en staat dat er de volgende dag nog? Dan zit je in webapplicatie-gebied. Toont de pagina voor iedereen dezelfde tekst, met hooguit een contactformulier, dan is het een website.

Die grens is niet scherp en dat is prima. Veel sites zitten er tussenin, en het is een fout om elk project in een van de twee vakjes te willen persen. Voor de keuze die je moet maken, namelijk wat je laat bouwen en wat het kost, maakt het wel uit aan welke kant je zit.

De drie begrippen worden door elkaar gebruikt, ook door leveranciers. Zo houden wij ze uit elkaar.

• Website is gemaakt om te lezen en te vinden. Denk aan een bedrijfssite, een kennisbank of een folder op internet. Inhoud verandert af en toe, bezoekers blijven anoniem.
• Webapplicatie is gemaakt om te doen. Je logt in, de applicatie kent jouw gegevens en rechten, en je werk wordt bewaard. Het draait in de browser op elk apparaat.
• Native app is geschreven voor één besturingssysteem, zoals iOS of Android, en komt via een appstore op het toestel. Daardoor heeft ze de meeste toegang tot hardware zoals camera, sensoren en pushmeldingen.
• Progressive Web App is een webapplicatie met een manifest en een service worker, waardoor je haar kunt installeren en beperkt offline kunt gebruiken.

Een voorbeeld van een grensgeval is de website die we bouwden voor Saga Driehuis. Het is een WordPress-site met digitale formulieren voor het aanmeldproces en een automatisch volgnummer op basis van voorrangsregels. Het grootste deel is nog steeds informatie, dus we noemen het een website met een stukje applicatielogica. Het collegeplatform van OGJG, verderop in dit artikel, is daarentegen volledig een webapplicatie.

Bij Fitr, een platform met aparte dashboards voor gebruikers en specialisten, hebben we juist beide gebouwd, een responsive webapplicatie en een native mobiele app in React Native. Dat is geen standaardkeuze. Het kan zinvol zijn als je zowel de brede bereikbaarheid van het web als de toestelfuncties van een app nodig hebt. Voor de meeste zakelijke toepassingen volstaat één van de twee, en dan is de webapplicatie meestal het praktischere startpunt.

Wie de afweging tussen web en app dieper wil uitwerken, vindt die in onze vergelijking native app of PWA en in het artikel mobiele app of webapp, wat past bij je bedrijf. Over de installeerbare variant staat meer in Progressive Web Apps. MDN omschrijft een PWA als een app die met webtechnologie is gebouwd maar aanvoelt als een platformspecifieke app.

Onder de motorkap werkt elke webapplicatie met dezelfde vier onderdelen. Het helpt om ze één keer te kennen, want daar zitten ook de kosten en de risico's.

De browser en de voorkant. Dit is wat je ziet en aanklikt. De voorkant is geschreven in HTML, CSS en JavaScript, vaak met een raamwerk zoals React. Ze stuurt een verzoek naar de server zodra je iets doet.

De server en de API. Een server ontvangt dat verzoek, controleert of je het mag doen en voert de bedrijfsregels uit. Volgens MDN haalt een dynamische site daarvoor de gegevens uit een database en bouwt ze daarmee het antwoord op, in plaats van voor elke pagina een los bestand te bewaren. De afspraken waarmee voorkant en server praten heten een API. Dezelfde API kan later ook door een mobiele app of een ander systeem worden gebruikt.

De database. Hier staan klanten, orders, gebruikers en rechten. Bij de projecten die we hierna noemen gaat het steeds om PostgreSQL, een beproefde relationele database. Alles wat je als gebruiker invoert moet hier veilig terechtkomen, en alles wat een collega moet zien komt hier weer uit.

Inloggen. Een webapplicatie moet jou van je collega kunnen onderscheiden. Na het inloggen krijgt je browser meestal een sessiecode in een cookie. Bij elk volgend verzoek stuurt de browser die mee en herkent de server je, zoals MDN uitlegt. Daarbovenop komen rollen. Een medewerker ziet andere schermen en mag andere dingen dan een klant of een beheerder, en die controle hoort op de server te zitten, niet alleen in de interface.

Daar komt hosting bij, wat gewoon betekent dat de server ergens draait en bereikbaar is, met back-ups en monitoring. Veel koppelingen met andere software, zoals betaalproviders of een transportsysteem, lopen via diezelfde API-laag.

Voorbeelden uit de buitenwereld vertellen je weinig over wat erbij komt kijken. Daarom beschrijven we vier opdrachten die we zelf hebben uitgevoerd, met alleen wat in de projectbeschrijvingen staat.

OGJG, collegeplatform voor senioren. Stichting Oud Geleerd Jong Gedaan verkocht online colleges eerst per ticket via een webshop. Nu staat er een eigen platform waar leden een jaarabonnement hebben met 14 dagen proefperiode, live colleges volgen en opgenomen colleges terugkijken. Na het inloggen zien ze in Mijn OGJG wat eraan komt. Het team beheert colleges, leden en mails in een eigen backoffice. De publieke stichtingssite bleef WordPress. Dat is een mooi voorbeeld van de scheiding die we hierboven beschreven, met een website als voorkant en een webapplicatie als ledenomgeving. In de technologielijst van het project staan onder meer Next.js, PostgreSQL, Mollie voor betalingen en Cloudflare R2 voor opslag.

Overseas Courier Service, zendingenportaal. OCS verwerkt internationale zendingen en werkte met verouderde systemen die niet met elkaar praatten, waardoor medewerkers dezelfde gegevens meerdere keren invoerden. We bouwden een portaal dat als centrale bron voor zendinggegevens dient, gekoppeld aan hun Orbitrax-transportsysteem. Medewerkers zien in één dashboard de status van alle zendingen, de voorraad, en krijgen meldingen bij afwijkingen. Hier zit de waarde in de koppeling en de regels, niet in het uiterlijk.

Refront, workflowplatform. Refront zet gesprekken om in offertes, tickets en facturen. Gelogde uren stromen door naar facturen, en betalingen lopen via Stripe. Het is gebouwd als SaaS-platform, waarin andere bedrijven inloggen en hetzelfde product gebruiken. Daarover meer in de kennisbankpagina over SaaS. Een SaaS-product is in feite een webapplicatie die aan veel klanten tegelijk wordt aangeboden.

Fitr, platform met twee dashboards. Gebruikers zoeken een specialist, specialisten beheren hun profiel, tarieven en beschikbaarheid. Een leadsysteem koppelt beide groepen op locatie, specialisme en beschikbaarheid. Dit is het klassieke voorbeeld van rollen, met twee typen gebruikers die allebei dezelfde database gebruiken.

Wat deze vier gemeen hebben, is dat een gebruiker er niet komt om te lezen. Hij komt om iets af te maken, en de applicatie onthoudt hoe ver hij is.

Een website kun je grotendeels laten staan. Een webapplicatie niet, want ze bewaart gegevens van mensen en praat met andere systemen. Dat betekent HTTPS, een goede inlog, controle van alles wat gebruikers invoeren en afspraken over wie er bij welke gegevens mag. Ook als je koppelingen hebt, moet iemand opmerken wanneer een externe partij iets wijzigt.

Toegankelijkheid is een tweede punt dat bij een webapplicatie sneller telt dan bij een brochuresite, omdat gebruikers er echt in moeten werken. De internationale standaard WCAG van het W3C beschrijft hoe je webinhoud en webapplicaties toegankelijk maakt volgens vier principes, namelijk waarneembaar, bedienbaar, begrijpelijk en robuust. In de praktijk betekent het dat iemand zonder muis kan werken en dat een schermlezer de structuur begrijpt. Welke verplichtingen daarbij horen voor jouw organisatie lees je in ons artikel over toegankelijkheid en de wet.

Onderhoud is het derde punt. Na livegang blijven er updates van onderdelen, monitoring en back-ups. Reken dat mee in je begroting, want het verschil tussen een applicatie die tien jaar meegaat en een die na twee jaar wordt vervangen zit vaak in dit deel.

Niet elk probleem vraagt om maatwerk. Voor boekhouden, e-mail, een standaard CRM of projectbeheer bestaat uitstekende standaardsoftware, en dan is kopen bijna altijd verstandiger dan bouwen. Het onderhoud ligt bij de leverancier, je kunt snel starten en de kosten zijn voorspelbaar.

Een eigen webapplicatie wordt interessant in een paar situaties.

• Je proces is jouw concurrentievoordeel en past niet in de vaste structuur van een pakket.
• Je plakt nu drie tools en een spreadsheet aan elkaar en mensen typen dezelfde gegevens meerdere keren over.
• Klanten of partners moeten in jouw omgeving inloggen, met eigen rechten en jouw huisstijl.
• Je wilt een koppeling met een specifiek systeem zoals een transportplanning of boekhouding die standaardsoftware niet of slecht biedt.

Ook de tussenvorm bestaat. Je gebruikt standaardsoftware voor wat standaard is en bouwt alleen het deel dat jou onderscheidt, gekoppeld via API's. Bij OGJG bleef de publieke site op WordPress staan en kreeg alleen het ledenwerk een eigen platform. Zo hou je het bouwdeel klein. Een uitgebreide afweging staat in maatwerk of SaaS, wanneer bouwen en wanneer kopen.

Een webapplicatie laten bouwen begint niet bij techniek maar bij het proces. Schrijf op wie de gebruikers zijn, wat ze moeten kunnen afronden, welke gegevens daarbij horen en met welke systemen gekoppeld moet worden. Beperk de eerste versie tot wat dagelijks terugkomt. Een tweede ronde gaat sneller en beter als echte gebruikers al hebben gewerkt met de eerste.

De kosten hangen vooral af van het aantal rollen, het aantal koppelingen en de hoeveelheid regels en uitzonderingen. Een indicatie krijg je met de calculator. Hoe wij zo'n traject aanpakken, van intake tot beheer, staat op de pagina webapplicatie laten bouwen.

Weet je nog niet zeker of jouw situatie een webapplicatie vraagt of een slimmere inrichting van wat je al hebt? Dat is een goede vraag voor een eerste gesprek. Soms is het antwoord dat je niets hoeft te laten bouwen.

Een webapplicatie is software in de browser waarin je iets afmaakt, omdat ze je herkent, bewaart je gegevens en voert regels uit op een server met een database. Een website toont vooral informatie, een native app draait op het toestel zelf, en een Progressive Web App zit daar tussenin. De keuze draait om het proces dat je wilt ondersteunen, niet om de techniek.

Begin met de vraag welk werk nu handmatig of dubbel gebeurt, kijk of standaardsoftware dat al oplost, en bouw alleen wat jou echt onderscheidt.