Webapplicatie laten ontwikkelen: van idee tot livegang in 7 stappen

Een paar voorbeelden uit onze praktijk:

• Een klantenportaal waar klanten bestellingen inzien, facturen downloaden of gegevens beheren
• Een kennisbank waar medewerkers en eindgebruikers informatie opzoeken, artikelen toevoegen en filteren op onderwerp
• Een dashboard met openstaande taken, statistieken en berichten
• Een boekingssysteem zoals EasyPaymentSports waar klanten zelf afspraken inplannen of tickets reserveren
• Een samenwerkingstool waar teams projecten beheren, bestanden delen en commentaar geven

Dit zijn geen showcases, maar tools die organisaties efficiënter maken en helpen om door te groeien.

Wanneer heb je een webapplicatie nodig?

Dit is misschien wel de belangrijkste vraag van het hele traject. Een webapplicatie kost meer voorbereiding en meer onderhoud dan een website, dus het is goed om vooraf te toetsen of de vraag echt om een applicatie roept. We zien doorgaans een aantal patronen terug.

Je processen draaien op spreadsheets en e-mail. Teams werken met gedeelde Excel-bestanden, sturen formulieren heen en weer per mail, of houden handmatig bij wat er waar staat. Dat werkt tot een bepaald punt, daarna wordt het foutgevoelig en onbeheersbaar.

Klanten of medewerkers vragen om selfservice. Ze willen zelf hun gegevens inzien, een bestelling volgen, een afspraak maken of een document downloaden, zonder telefoon of mail.

Je groeit sneller dan je systemen aankunnen. Wat ooit prima werkte voor tien medewerkers kraakt bij vijftig. Processen die handmatig liepen kosten nu te veel tijd en te veel mensen.

Je hebt realtime inzicht nodig. Je wilt op elk moment weten hoe het ervoor staat, met projecten, met klanten, met voorraad of met openstaande taken. Niet morgen, niet volgende week, maar nu.

Herken je een of meer van deze situaties? Dan is een webapplicatie waarschijnlijk de juiste oplossing.

Het ontwikkelproces in 7 stappen

1. Stap 1: Ontdekfase

   Alles begint met de vraag: wat proberen we eigenlijk op te lossen? In de ontdekfase breng je samen in kaart wat er nodig is. Wie zijn de gebruikers? Welke processen moeten ondersteund worden? Welke systemen moeten gekoppeld worden? Een goede ontdekfase gaat verder dan alleen wensen ophalen. Het draait ook om het scherp krijgen van doelen. Wat moet de applicatie opleveren? Efficiënter werken, minder fouten, betere dienstverlening? Door stakeholders te betrekken en bestaande processen te analyseren, leg je een stevig fundament voor de rest van het traject.

2. Stap 2: Functioneel ontwerp

   Op basis van de ontdekfase wordt een functioneel ontwerp gemaakt. Dit beschrijft wat de applicatie moet doen, welke schermen er komen en hoe gebruikers erdoorheen navigeren. Geen code, maar een duidelijke blauwdruk. In de praktijk wordt dit vaak uitgewerkt in user stories en een backlog. Dat maakt het minder statisch en beter geschikt voor een iteratieve aanpak. Zo kun je tijdens het project blijven bijsturen zonder dat alles opnieuw moet worden bedacht.

3. Stap 3: UX/UI design

   Nu wordt het visueel. Designers maken wireframes en ontwerpen die niet alleen aantrekkelijk zijn, maar vooral logisch en gebruiksvriendelijk. Toegankelijkheid speelt hierbij een belangrijke rol. Door vanaf het begin rekening te houden met WCAG-richtlijnen voorkom je dat dit later nog “gerepareerd” moet worden. Daarnaast ligt de focus op duidelijke gebruikersflows, zo min mogelijk frictie en een interface die aansluit bij verschillende doelgroepen.

4. Stap 4: Development

   In deze fase wordt de applicatie daadwerkelijk gebouwd. Vaak gebeurt dit in sprints van twee weken, waarbij na elke sprint wordt opgeleverd en geëvalueerd. Dat zorgt voor inzicht en flexibiliteit tijdens het proces. Er wordt meestal gewerkt met open source technologieën zoals Laravel, Drupal of React. Afhankelijk van de situatie wordt gekozen voor maatwerk of het slim inzetten van bestaande componenten. Belangrijk in deze fase is dat er niet alleen gebouwd wordt, maar ook vooruit wordt gedacht. Hoe schaalbaar is de oplossing? Hoe eenvoudig is deze te onderhouden? Dit soort keuzes maken op lange termijn een groot verschil. Daarnaast wordt er gewerkt met gescheiden omgevingen (bijvoorbeeld ontwikkel, test, acceptatie en productie), zodat wijzigingen gecontroleerd en veilig kunnen worden doorgevoerd.

5. Stap 5: Testen

   Testen gaat verder dan alleen controleren of alles werkt. Er wordt gekeken naar functionaliteit, performance, beveiliging en toegankelijkheid. Minstens zo belangrijk is het testen met echte gebruikers. Door scenario’s uit de praktijk na te bootsen, komen vaak inzichten naar voren die je vooraf niet had bedacht. In moderne ontwikkeltrajecten is kwaliteit geen losse fase, maar iets dat continu meeloopt. Denk aan code reviews, automatische checks en aandacht voor security.

6. Stap 6: Training en overdracht

   Een applicatie is zo goed als de mensen die ermee werken. Daarom is het belangrijk dat teams goed worden meegenomen in het gebruik ervan. Dit gebeurt vaak via praktische trainingen en duidelijke documentatie. Daarnaast helpt het als de backend aansluit op de manier waarop een organisatie werkt. Dat maakt het beheer overzichtelijker en verlaagt de drempel voor dagelijks gebruik.

7. Stap 7: Livegang

   De livegang is een belangrijk moment, maar zeker niet het eindpunt. Vooraf worden controles uitgevoerd op zaken zoals performance, beveiliging en technische inrichting. Denk aan caching, monitoring en back-ups. Na de lancering volgt meestal een periode van intensieve monitoring en kleine optimalisaties. In de praktijk blijkt dat een applicatie nooit “af” is. Door continu door te ontwikkelen en te verbeteren, blijft deze aansluiten op de behoeften van gebruikers en de organisatie.

Welke technologie kies je?

De technologiekeuze hangt af van wat je applicatie moet doen. Er is geen pasklare oplossing die altijd werkt en in de praktijk combineren we vaak meerdere technologieën tot één passend geheel.

Drupal is ideaal voor webapplicaties met veel content: kennisbanken, portalen met duizenden pagina’s, meertalige omgevingen. Drupal blinkt uit in content-modellering, in rechten en rollen, en in het beheren van complexe informatiearchitecturen.

Laravel is de keuze voor maatwerk. Als je applicatie draait om bedrijfslogica, workflows, berekeningen of integraties met externe systemen, biedt Laravel de flexibiliteit die je nodig hebt. Lees ook ons artikel over hoe je het beste een maatwerkapplicatie laat ontwikkelen voor de afweging tussen pakketten en maatwerk, of wanneer kies je voor WordPress, Drupal of Laravel als je nog twijfelt over de basiskeuze.

React zetten we in voor de frontend wanneer de gebruikerservaring extra belangrijk is. Realtime updates, complexe formulieren, drag-and-drop of een applicatie die aanvoelt als een desktopprogramma. Een mooi tussenoplossing voor Laravel-applicaties is InertiaJS, waarmee je React combineert zonder een aparte tussenlaag te bouwen waarmee de twee systemen met elkaar praten.

In de praktijk combineren we deze technologieën regelmatig: Drupal als content-backend, React als frontend en Laravel voor specifieke bedrijfslogica. De juiste mix hangt af van wat jouw situatie vraagt.

AI in webapplicatie-ontwikkeling, wat verandert er?

Dat AI invloed heeft op hoe wij applicaties bouwen valt niet meer te negeren. Bij vrijwel ieder kennismakingsgesprek de afgelopen maanden komt AI ter sprake. Soms uit nieuwsgierigheid ("kan AI hierin een rol spelen?"), soms uit zorg ("hoe gebruiken jullie zelf AI in het ontwikkeltraject?"). Hier een eerlijke uiteenzetting van wat AI op dit moment voor jouw project betekent, wat we er wel en niet mee doen, en hoe we omgaan met de risico’s.

Wat AI nu wel goed doet. AI-hulpmiddelen die specifiek voor programmeurs zijn gemaakt, zoals Cursor, Claude Code en GitHub Copilot, versnellen een deel van het routinematige werk. Standaardcode genereren die anders met de hand getypt moet worden, eenvoudige tests opzetten, een eerste versie van documentatie schrijven, voorstellen doen om bestaande code op te schonen, of de eerste opzet van een koppeling met een externe dienst maken op basis van de documentatie van die dienst. Voor onze ontwikkelaars scheelt dat in de praktijk tijd, en die tijd gaat naar het lastigere werk: architectuur, datamodel, security, performance.

Wat AI ook kan, maar voorzichtiger. Hele features bouwen op basis van een korte, globale opdracht. Het is mogelijk en het werkt soms verbluffend goed, alleen is de output niet altijd code die we zonder kritische review zouden inchecken. We zien geregeld code voorbij komen die werkt, maar die niet aansluit bij de bestaande conventies, die security-aannames negeert, of die afhankelijkheden binnenhaalt waar we anders nooit voor zouden kiezen. AI lost de implementatie op, niet de vraag of die implementatie de juiste is voor jouw situatie.

De risico’s die we serieus nemen:

• AI verzint soms dingen. Functies, instellingen of softwarecomponenten die in werkelijkheid helemaal niet bestaan. In een live applicatie wil je dat niet.
• Security-aannames. AI levert standaard niet altijd de meest veilige variant. Inloggen, rechten beheren en het controleren van wat een gebruiker invult vereisen menselijke aandacht.
• Technische schuld. Snel gegenereerde code zonder review hoopt op. Wat in een prototype prima is, kost in productie alsnog tijd om op te ruimen.
• Vendor-afhankelijkheid. Het maakt uit op welk model je leunt. Wisselingen in modelgedrag of tarieven raken je workflow direct.
• Onbedoeld delen van bedrijfsgegevens. Klant- of bedrijfsinformatie die in een AI-vraag wordt meegestuurd, komt al snel bij de leverancier van het AI-model terecht. Dat hoort niet zomaar te gebeuren.

Hoe wij ermee werken bij Emble. Pragmatisch, niet dogmatisch. We zetten AI elke dag in als directe hulp voor onze ontwikkelaars, vooral voor het werk waar het in uitblinkt: tests schrijven, bestaande code opschonen, mogelijkheden verkennen en documentatie opstellen. Voor architectuurkeuzes, datamodel-beslissingen en alles dat met security en performance te maken heeft, is een ervaren ontwikkelaar nog steeds leidend. Een collega die de code controleert voor we iets live zetten blijft niet-onderhandelbaar. AI maakt onze ontwikkelaars krachtiger, het vervangt ze niet.

Wat dat voor jou betekent. Voor sommige onderdelen van een traject leveren we sneller dan een paar jaar geleden. Een werkend prototype, een eerste versie van een dashboard of een proof of concept op een dataset zijn we sneller in. Voor het echte applicatie-werk, met schaal, security en jarenlange houdbaarheid, blijft de doorlooptijd ongeveer gelijk. AI maakt ons werk anders, niet automatisch goedkoper. Lees ook onze diepere kijk in de impact van AI agents op het ontwikkelen van Drupal websites of bekijk wat we doen rond Drupal AI.

Wat kost een webapplicatie laten ontwikkelen?

Eerlijk gezegd hangt dat sterk af van wat je wilt. Net als bij het bouwen van een huis bepalen grootte, complexiteit en afwerkingsniveau de prijs. Toch geven we hieronder ranges die we in de praktijk vaak zien, zodat je een idee hebt wat je budget moet zijn voordat we in detail gaan.

Factoren die de prijs bepalen:

• Complexiteit van de functionaliteit. Een eenvoudig klantenportaal is een ander verhaal dan een platform met workflows, rechten en rollen, en koppelingen.
• Aantal externe integraties. Iedere koppeling met een CRM, een ERP, een PIM of een betaalprovider vraagt eigen werk en eigen testing.
• Mate van maatwerk in design. Standaardcomponenten gaan sneller dan een uniek design met eigen interactiepatronen.
• Toegankelijkheidseisen en compliance. WCAG 2.2, BIO/NIS2 en AVG zijn geen kleine vinkjes als je het serieus aanpakt.
• Schaal. Een applicatie voor honderd gebruikers ontwerp je anders dan een platform voor honderdduizend.

Indicatieve ranges. Een eenvoudige applicatie zit tussen de 15.000 en 30.000 euro. Een middelgrote applicatie met meerdere rollen en integraties tussen de 30.000 en 75.000 euro. Complexe platformen met veel functionaliteit en hoge schaalbaarheid komen boven de 100.000 euro uit. Bij langlopende samenwerkingen werken we ook met flexibele doorontwikkeldagen, zodat je geen groot bedrag in een keer hoeft vast te leggen.

Veelgemaakte fouten en hoe je ze voorkomt

Te veel willen in de eerste versie. Begin met een MVP, een Minimum Viable Product, en bouw vanuit daar door. Je leert het meest van echte gebruikers, niet van een uitputtend eisenpakket dat een jaar oud is voor het in productie staat.

Geen echte gebruikers betrekken. Test niet alleen intern. Laat de mensen die straks dagelijks met de applicatie werken meekijken en feedback geven, en laat hen dat zo vroeg mogelijk doen.

Onderhoud onderschatten. Een webapplicatie is nooit klaar. Na livegang volgen updates, beveiligingspatches, nieuwe wensen en technische verbeteringen. Plan hier budget voor, anders wordt het na een jaar pijnlijk.

De verkeerde technologie kiezen. Kies niet voor een combinatie van technologieën omdat die hip is, maar omdat die past bij je vraagstuk. Een ervaren partner helpt je bij die afweging in plaats van zomaar zijn favoriete combinatie van technologieën op te leggen.

Te weinig aandacht voor toegankelijkheid en security. Beide zijn moeilijker en duurder achteraf in te bouwen dan vooraf. Neem ze als ontwerpcriteria mee, niet als bijzaak die je er later nog wel bij doet.

Na de livegang, onderhoud en doorontwikkeling

Een webapplicatie lanceren is niet het einde, maar het begin. Gebruikers ontdekken nieuwe behoeften, je organisatie verandert, en de technologie zelf ontwikkelt door, zeker in een tijd waarin AI-features de standaardverwachting beginnen te worden.

Wij bieden flexibele doorontwikkeldagen waarmee je op je eigen tempo verbeteringen doorvoert, zonder langlopende contracten met starre uren. Voor klanten met een Laravel-applicatie hebben we Laravel ondersteuning, en voor Drupal lopen verschillende vormen van Drupal support, onderhoud en beheer.

Deel dit artikel