Hoe laat je het beste een maatwerkapplicatie ontwikkelen?

In dit artikel neem ik je stap voor stap mee door het traject, van strategie tot hosting en van app store tot intellectueel eigendom. Je ontdekt wat werkt, waar het vaak misgaat en hoe je samen met de juiste partner een applicatie ontwikkelt die écht waarde toevoegt.

Wanneer kies je voor maatwerk?

Voordat je in de wereld van maatwerk duikt, is het slim om jezelf eerst deze vraag te stellen: heb ik het echt nodig? Want maatwerk vraagt tijd, geld en aandacht. Dan wil je zeker weten dat je iets krijgt wat je met bestaande software niet voor elkaar krijgt.

Maatwerk is vooral interessant als jouw processen of ideeën echt afwijken van het gemiddelde. Misschien wil je sneller en efficiënter werken dan je concurrenten, of heb je unieke wensen waar geen standaardpakket op aansluit. Dan kan een op maat gemaakte applicatie precies dat verschil maken.

Heb je vooral generieke wensen en ben je bereid je processen aan te passen aan wat bestaande software biedt, dan is een standaardoplossing vaak sneller en voordeliger.

Begin bij het probleem

Een goede applicatie begint niet met techniek, maar met een helder doel. Wat wil je bereiken? Voor wie doe je dit? En waarom?

Breng eerst je bedrijfsdoelen scherp in kaart en denk goed na over de eindgebruikers. Gaat het om klanten, collega’s of inwoners? Wat hebben zij nodig om soepel te kunnen werken of navigeren?

Het helpt enorm om verschillende mensen in je organisatie hierbij te betrekken. De inzichten van gebruikers, managers en IT’ers geven samen een realistischer beeld van wat er nodig is en wat prioriteit heeft.

Kijk ook kritisch naar je huidige processen. Waar zit de meeste frustratie of inefficiëntie? Leg die pijnpunten vast, zodat je voorkomt dat je straks iets automatiseert wat eigenlijk al overbodig is. Een veelgemaakte fout is namelijk het klakkeloos digitaliseren van bestaande processen zonder ze eerst te herzien. Durf dus ook te schrappen. Soms levert iets weglaten meer op dan iets bouwen.

Wat zijn je opties?

Als je weet wat je wilt bereiken, komt de volgende vraag: hoe ga je dat realiseren? Er zijn meerdere routes mogelijk, allemaal met hun eigen voordelen en aandachtspunten.

# Standaardsoftware of SaaS

Misschien bestaat er al een softwarepakket of SaaS-oplossing die grotendeels aansluit op jouw wensen. Zo’n standaardoplossing is vaak snel in gebruik te nemen en technisch gezien goedkoper. De keerzijde is dat je je processen moet aanpassen aan wat de software biedt, niet andersom. Je bent bovendien afhankelijk van de leverancier. Je kunt niet alles aanpassen zoals jij het wilt en zit vast aan hun updates, tempo en roadmap.

# Zelf ontwikkelen met een eigen team

Heb je een eigen IT-team met voldoende kennis en capaciteit? Dan kun je overwegen om zelf te bouwen. Je houdt dan alles in eigen hand en kunt snel schakelen. Maar pas op: software bouwen is een vak apart. Denk aan moderne technieken, UX, beveiliging, schaalbaarheid. Bovendien mis je dan de frisse blik van een externe partij, die vaak veel best practices meebrengt uit andere projecten.

# No-code of low-code tools

No-code platforms zijn de afgelopen jaren sterk ontwikkeld. Je kunt er zonder te programmeren relatief snel een tool mee bouwen. Handig voor interne processen of een eerste proof-of-concept. Voor eenvoudige toepassingen werkt het prima. Maar zodra het complex wordt, met geavanceerde logica, koppelingen of performance-eisen, loop je al snel tegen grenzen aan. Ook zit je vaak vast aan het gekozen platform. Overstappen betekent meestal opnieuw beginnen.

# Een maatwerkapplicatie laten ontwikkelen

De meest flexibele aanpak blijft het laten bouwen van een maatwerkapplicatie door een gespecialiseerd bureau. Jij bepaalt hoe alles werkt, welke functies erin komen, hoe het eruitziet en hoe het integreert met andere systemen. De applicatie sluit precies aan op jouw organisatie. Het vraagt een grotere investering, maar levert ook meer op: grip, kwaliteit, schaalbaarheid en toekomstvastheid.

Wat kies je wanneer?

Veel organisaties starten klein. Bijvoorbeeld met een no-code prototype, gebouwd door een collega met een goed idee. Dat is een prima manier om te testen wat wel en niet werkt, feedback op te halen en inzichten op te doen. Maar zodra de applicatie serieuzer wordt, is het vaak slimmer om over te stappen naar een duurzame oplossing.

Een veelgebruikte aanpak is dan ook: begin met no-code om te experimenteren, en kies voor maatwerk zodra het serieus wordt.

Wees eerlijk over wat je zelf in huis hebt. Iets bouwen dat “werkt” is één ding. Maar een applicatie die ook veilig, gebruiksvriendelijk en schaalbaar is, vraagt om ervaring en specialisme. Heb je die kennis niet intern, dan kom je uiteindelijk beter uit met een professioneel bureau. Dat scheelt niet alleen tijd, maar voorkomt ook kostbare fouten.

Technische keuzes: webapplicatie, PWA of native mobiele app?

Een belangrijke beslissing bij het ontwikkelen van een maatwerkapplicatie is het type applicatie dat je laat bouwen. Wordt het een webapplicatie die werkt via de browser, een mobiele app voor iOS en Android, of een tussenvorm zoals een Progressive Web App (PWA)? Je keuze heeft invloed op de gebruikerservaring, ontwikkelkosten, distributie en onderhoud.

# Webapplicatie

Een webapplicatie is in de basis een website die werkt als een volwaardige applicatie. Gebruikers openen de app via hun browser, op een computer, tablet of smartphone. Installatie is niet nodig. Alles draait online, bereikbaar via een simpele URL.

Het grote voordeel: een webapp werkt overal. Of iemand nu op een Windows-pc, Mac, iPhone of Android-telefoon werkt, het maakt niet uit. Updates zijn eenvoudig: je past de code aan op de server en iedereen gebruikt meteen de nieuwste versie. Geen gedoe met app stores of installatieproblemen.

Moderne webapps kunnen steeds meer. Denk aan offline werken, caching en pushmeldingen. Daarmee komen ze dicht in de buurt van een native app. En dan komen we bij de PWA.

# Progressive Web App (PWA)

Een PWA is een webapplicatie die aanvoelt als een native app. Je kunt een app iccon op je start / homescreen zetten, hij opent fullscreen, werkt vaak deels offline en je kunt zelfs functies als push notificaties toepassen. Technisch gezien is het nog steeds een website, maar dan eentje die slim is opgebouwd met moderne technieken.

Grote spelers als X, Pinterest en Uber gebruiken PWA’s om hun diensten breed toegankelijk te maken zonder aparte apps voor elk platform.

Het voordeel is duidelijk: met één codebase bedien je iedereen. Dat scheelt in ontwikkeling én onderhoud. Je hoeft ook geen app store in, gebruikers kunnen direct aan de slag via een link. Dat verlaagt de drempel.

Er zijn wel beperkingen. PWA’s hebben minder toegang tot functies van het apparaat dan native apps. Denk aan zaken als NFC, biometrie (vingerafdruk) of uitgebreide Bluetooth-functies. Ook qua zichtbaarheid in app stores en verdienmodellen (zoals in-app aankopen) zijn er haken en ogen. Toch is een PWA vaak een slimme keuze als je een brede doelgroep wilt bereiken met relatief lage instapdrempels.

Een goed voorbeeld is de wijkapp ‘Samen Kampen’ die we bij Emble ontwikkelden. Deze werkt op elk apparaat, zonder installatie. Bewoners krijgen per wijk toegang tot nieuws, activiteiten en een prikbord. Alles draait in één centrale webapp, gebouwd in React / Next.js een frontend techniek die uitermate geschikt is om PWA’s mee te ontwikelen. Voor de backend gebruikten we Drupal, flexibel als het gaat om het inrichten van rollen en rechten en tegelijkertijd een bekend systeem bij gemeenten door heel Nederland omdat de meesten werken met Drupal voor de website van de Gemeente zelf.

# Native mobiele app

Een native app wordt speciaal ontwikkeld voor iOS of Android. Hierdoor heb je toegang tot alle mogelijkheden van het apparaat: camera, GPS, biometrie en meer. De app wordt via de app stores verspreid en biedt vaak de meest soepele gebruikservaring, zeker bij zware toepassingen of complexe logica.

Het nadeel: je hebt aparte apps nodig voor iOS en Android, met bijbehorende ontwikkelkosten. Ook kost het publiceren in app stores tijd en moeite, en moet je voldoen aan de strikte richtlijnen van Apple en Google.

Native is vooral interessant als je performance of apparaatfuncties nodig hebt die je via web of PWA niet kunt bieden. Bijvoorbeeld bij consumentenapps waarbij gebruikservaring het verschil maakt.

Samenvattend

Laat je keuze voor het type applicatie afhangen van je doel. Wil je brede toegankelijkheid, eenvoudig beheer en geen complexe hardwarekoppelingen? Dan is een webapp of PWA vaak het slimst. Gaat het om maximale performance, zichtbaarheid in app stores of integratie met specifieke toestel­functies? Dan kom je al snel uit bij native. Soms is een hybride aanpak ook een goede stap. Begin met een webapp om ervaring op te doen en investeer pas in native als je zeker weet wat gebruikers écht nodig hebben.

Testing & kwaliteitsbewaking

De kwaliteit van je maatwerkapplicatie staat of valt met goed testen. Professionele ontwikkelaars schrijven tijdens het bouwen al tests maar dat is niet genoeg omdat die zich meestal richten op de werking van code. Uiteindelijk gaat het erom of de applicatie in de praktijk doet wat jij en je gebruikers ervan verwachten.

Plan daarom voldoende tijd in voor testmomenten. Dat begint intern, met tests door het ontwikkelteam. Maar ook gebruikersacceptatietesten zijn essentieel. Idealiter start je daar al vroeg mee, bijvoorbeeld aan het eind van elke sprint. Zo kun je nieuwe onderdelen direct beoordelen en voorkom je dat je aan het eind van het project wordt verrast door een stapel ongeteste functionaliteiten.

Een belangrijke rol hierin ligt bij de product owner. Die bewaakt de scope en prioriteiten, en zorgt ervoor dat de juiste mensen op het juiste moment meekijken. Denk aan stakeholders uit de business of eindgebruikers uit de praktijk. Het is de taak van de PO om feedback op te halen, keuzes te onderbouwen en ervoor te zorgen dat de applicatie aansluit bij de doelen van de organisatie.

Testen draait trouwens niet alleen om het opsporen van bugs. Het gaat ook om logica, verwachtingen en gebruiksvriendelijkheid. Laat de applicatie bijvoorbeeld eens testen door iemand die het project nog niet kent. Begrijpt diegene wat er moet gebeuren? Dat levert vaak waardevolle inzichten op die je intern al over het hoofd ziet.

Heeft jouw organisatie specifieke kwaliteitsstandaarden, zoals WCAG-eisen of minimumeisen voor performance? Neem die dan expliciet mee in je testplan. Bij Emble doen we dat standaard. En vergeet security niet. Afhankelijk van de gevoeligheid van de data kunnen extra maatregelen nodig zijn, zoals een penetratietest of een audit. Zo weet je zeker dat je applicatie niet alleen goed werkt, maar ook veilig en toegankelijk is.

En dan: livegang. Voor een webapp betekent dat meestal dat alles wordt uitgerold naar de productieomgeving, inclusief database en eventuele API’s. Voor mobiele apps komt daar nog het publicatieproces bij in de app stores, inclusief goedkeuring door Apple of Google.

Een zachte lancering (soft launch) is vaak slim. Daarmee geef je eerst een beperkte groep gebruikers toegang, zodat je eventuele kinderziektes nog in een veilige setting kunt oplossen. Informeer je gebruikers op tijd, vooral als je een bestaand systeem vervangt. Zorg ook na livegang voor goede ondersteuning: met documentatie, helpteksten, een FAQ en een aanspreekpunt voor vragen.

De eerste weken na livegang leveren vaak veel inzichten op. Gebruikers gaan écht aan de slag en lopen tegen dingen aan die je vooraf niet altijd kunt voorzien. Sta daarom open voor feedback, blijf monitoren en stuur aan wanneer nodig. De product owner speelt hierin een sleutelrol. Die verzamelt signalen uit de organisatie, stelt prioriteiten voor verbeteringen en schakelt met het ontwikkelteam om door te pakken waar nodig.

Een applicatie is nooit echt ‘af’, optimaliseren hoort erbij. Door kort op de bal te spelen en de juiste feedback te vertalen naar concrete verbeteringen, zorg je dat je applicatie steeds beter aansluit bij de praktijk.

Onderhoud en doorontwikkeling

Na de livegang begint er een nieuwe fase: zorgen dat je applicatie veilig, relevant en prettig in gebruik blijft. Onderhoud is geen bijzaak, maar een essentieel onderdeel van de levenscyclus.

Plan daarom structureel onderhoud in. Denk aan beveiligingsupdates, technische verbeteringen, prestatie-optimalisaties of het aanpassen van functies aan veranderende wensen. Veel bureaus bieden hiervoor een onderhoudsabonnement aan – en bij Emble doen we dat met iets extra’s: we kijken niet alleen naar de techniek, maar ook naar de impact en het gebruik.

Bij Emble geloven we dat een applicatie pas echt tot z’n recht komt als je ermee blijft werken en verbeteren. Daarom bieden we actieve doorontwikkeling aan. In overleg met jouw product owner of projectverantwoordelijke plannen we regelmatig doorontwikkeldagen in. Op basis van inzichten uit de praktijk, gebruikersfeedback of nieuwe wensen bepalen we waar de meeste waarde zit. Soms is dat een nieuwe functionaliteit, soms juist het versimpelen van iets dat niet goed blijkt te werken. 

Ook kleine verbeteringen houden we bij. Via korte lijnen kun je snel schakelen met ons team, je hebt direct contact met een vaste developer. We denken mee, geven advies en zorgen dat er altijd iemand beschikbaar is om door te bouwen of iets op te lossen. Zo schalen we op wanneer er grotere uitbreidingen nodig zijn door extra collega’s toe te voegen aan de doorontwikkeling en te werken in korte sprints die snel resultaat opleveren.

Valkuilen bij maatwerkontwikkeling (en hoe je ze voorkomt)

Een maatwerktraject biedt veel kansen, maar ook een paar bekende valkuilen. Als je die herkent en er vooraf op anticipeert, kun je veel gedoe voorkomen.

Een van de grootste risico’s is starten zonder duidelijke doelen of scope. Als je niet helder hebt wat je wilt bereiken, wat prioriteit heeft en wat er buiten het project valt, ontstaat er al snel ruis. Of je krijgt te maken met scope creeping: steeds meer wensen die tussendoor worden toegevoegd. Formuleer daarom vooraf concrete doelen en stel samen met je ontwikkelpartner duidelijke kaders.

Een andere valkuil is te veel vasthouden aan een vooraf bedacht idee. In de praktijk kom je gaandeweg nieuwe inzichten tegen. Soms blijkt een functie overbodig, of ontdek je een slimmere oplossing. Blijf dus flexibel. Prototypes en gebruikerstests helpen om die inzichten op tijd op te doen, in plaats van pas na oplevering.

Organisatorisch liggen er ook risico’s. Als er niemand is die knopen durft door te hakken, loopt het project vertraging op. Wijs daarom één persoon aan als intern aanspreekpunt met mandaat om beslissingen te nemen. Die product owner onderhoudt het contact met het ontwikkelteam en zorgt dat de vaart erin blijft.

Wees ook realistisch over tijd en geld. De combinatie “snel, goedkoop en perfect” is een utopie. Je zult keuzes moeten maken. Wil je topkwaliteit, dan vraagt dat vaak iets meer tijd of budget. Een goede ontwikkelpartner helpt je om daar de juiste balans in te vinden.

Wat ook regelmatig gebeurt: organisaties raken gaandeweg enthousiast en blijven maar wensen toevoegen. Heel begrijpelijk, maar daardoor wordt een applicatie vaak onnodig ingewikkeld of traag om op te leveren. Richt je liever op een sterke eerste versie: een MVP, oftewel een Minimum Viable Product. Dat is de kleinst mogelijke versie van je applicatie waarmee je de belangrijkste waarde kunt leveren aan je gebruikers.

In plaats van alles in één keer te willen bouwen, kies je ervoor om te starten met de kernfunctionaliteiten. Daarmee kun je snel live, testen in de praktijk en op basis van échte feedback gericht doorontwikkelen. Dat werkt beter, sneller én goedkoper dan vooraf alles proberen te bedenken en bouwen.

Uitbreiden kan altijd nog, en met een solide MVP als basis weet je veel beter wat er echt nodig is. Zo bouw je stap voor stap aan een applicatie die precies doet wat jouw organisatie nodig heeft.

Goede communicatie is minstens zo belangrijk. Neem gebruikers op tijd mee. Vertel waarom de applicatie er komt, wat het hen oplevert en hoe ze ermee aan de slag gaan. Herhaal je boodschap op meerdere momenten en in begrijpelijke taal. Dat vergroot de kans op draagvlak.

Kijk bij de keuze van techniek verder dan de hype. Een hip framework zonder actieve community of toekomstvisie kan later voor problemen zorgen. Kies liever voor bewezen technologie met een brede gebruikersgroep en actieve doorontwikkeling. Bij Emble werken we daarom meestal met open source zoals Drupal, Laravel of React.

Beveiliging en privacy zijn geen sluitposten. Denk vanaf het begin na over toegangsbeheer, versleuteling, logging en dataminimalisatie. Laat indien nodig een audit of penetratietest doen. Zeker met de AVG in je achterhoofd is dit een belangrijk punt van aandacht.

Een te krap budget of strakke planning werkt frustratie in de hand. Bouw ruimte in voor tegenslag, en werk transparant. Als het tegenzit, kun je dan samen bijsturen zonder dat het project ontspoort.

En tot slot: voorkom afhankelijkheid. Leg vast dat jij eigenaar bent van de code, kies bij voorkeur voor open source en zorg dat je na oplevering ook écht alles hebt wat je nodig hebt om zelfstandig verder te kunnen. Dan kun je ook in de toekomst flexibel blijven, wat er ook gebeurt.

Fouten helemaal voorkomen is niet realistisch. Maar als je weet waar de risico’s zitten, kun je ze grotendeels ontwijken, zeker met een ervaren partner aan je zijde die het klappen van de zweep kent.

Budget en scope bewaken: hoe houd je controle?

Een van de spannendste onderdelen van maatwerkontwikkeling is het budget. Meestal is het niet onbeperkt, en toch wil je er zoveel mogelijk waarde uithalen. Hoe zorg je dat de kosten beheersbaar blijven en je onderweg niet voor onaangename verrassingen komt te staan?

Alles begint met openheid. Vraag je ontwikkelpartner om een heldere kostenraming voor het hele traject. Een goed bureau werkt met realistische inschattingen en geeft bandbreedtes als er nog onzekerheden zijn. Check goed of alle onderdelen zijn meegenomen: ontwerp, ontwikkeling, testen, projectmanagement, licenties, API-koppelingen. En durf te vragen naar aannames als iets niet duidelijk is.

Bij complexere projecten is het slim om eerst een discoveryfase te doen. Daarmee scherp je samen de scope aan. Op basis daarvan volgt dan een concrete begroting voor het bouwen zelf. Bij Emble doen we dit in een Sprint 0. Een voorbereidende sprint waarin wensen en doelstellingen met het development team besproken wordt en waarbij inschattingen worden afgegeven en verschillende opties worden besproken. 

Ook de gekozen contractvorm heeft invloed. In grote lijnen heb je twee modellen: fixed price of time & material. Bij fixed price weet je vooraf wat het gaat kosten, maar je moet wel precies weten wat je wilt. De leverancier neemt risico’s mee in de prijs. Bij time & material betaal je voor wat er daadwerkelijk gebouwd wordt. Dat is flexibeler, maar vraagt meer betrokkenheid en sturing vanuit jouw kant.

Daarnaast helpt het enorm om te prioriteren. De MoSCoW-methode is daarbij een handige aanpak: verdeel je wensen in must-haves, should-haves, could-haves en won’t-haves. Als het budget krap wordt, weet je zo makkelijker waar je op kunt sturen. Begin met de kern, de rest kan later.

Zorg ook voor regelmatige updates over de voortgang en bestede uren. Veel bureaus, zoals Emble, werken met sprints en urenrapportages. Daarmee kun je op tijd bijsturen als iets uitloopt of tegenvalt. Het is fijner om dat halverwege te ontdekken dan pas bij de oplevering.

Flexibiliteit in de scope helpt ook. Spreek vooraf af dat je iteratief werkt. Als blijkt dat iets meer tijd kost dan gedacht, kun je iets anders tijdelijk parkeren zonder dat het hele project stilvalt. Liever een goed werkende basis dan een halve applicatie met alle toeters en bellen.

En reserveer altijd een buffer. Onvoorziene dingen gebeuren nu eenmaal, zeker bij iets nieuws. Een marge van tien tot vijftien procent is heel normaal. Heb je het niet nodig? Mooi. Maar als het wel nodig is en je hebt niets achter de hand, kom je in de knel.

Let er ook op dat je niet bespaart op zaken als testen, documentatie of beveiliging. Wat je daar op korte termijn mee wint, betaal je vaak later dubbel terug in frustratie of herstelwerk.

Tot slot: houd je organisatie aangehaakt. Zorg dat beslissers begrijpen waar het geld naartoe gaat, maar vooral ook wat het oplevert. Communiceer over mijlpalen, inzicht in kosten en toegevoegde waarde. Als iedereen het belang ziet, loopt je project een stuk soepeler.

Intellectueel eigendom en gebruiksrechten

Een vraag die vaak opkomt bij maatwerk: van wie is de code als het project klaar is? En hoe zit het met intellectueel eigendom?

De afspraken hierover leg je vast in het contract. De meeste opdrachtgevers willen volledige eigendom. Logisch: als jij iets hebt laten bouwen, wil je er ook vrij over kunnen beschikken. Je wilt zelf kunnen uitbreiden, een andere partij inschakelen of delen hergebruiken in andere software.

Sommige bureaus houden het eigendom formeel in eigen hand, maar geven jou een onbeperkt gebruiksrecht. Dat werkt prima, zolang alles goed is vastgelegd. Andere partijen hanteren een hybride model: het maatwerk is van jou, maar generieke onderdelen (zoals een intern ontwikkelde module) blijven van de ontwikkelaar. Ook dat is oké, zolang er geen onduidelijkheid over bestaat.

Onze tip: leg vast dat jij eigenaar wordt van de maatwerkcode zodra het project is afgerond en betaald. Zo behoud je maximale controle. Bij Emble is dat standaard. Wij vinden het vanzelfsprekend dat jij beschikt over wat je hebt laten maken.

Let ook op het gebruik van open source. Die code blijft onder de bijbehorende licentie vallen, maar dat is meestal juist een voordeel: je mag het vrij gebruiken, aanpassen en delen. Zolang je weet onder welke voorwaarden dat mag, zit je goed.

Een goed voorbeeld is het intranet dat we bouwden voor het Planbureau voor de Leefomgeving. Volledig gebaseerd op open source technologie, zodat ze niet langer afhankelijk zijn van een specifieke leverancier.

Zorg na oplevering dat je toegang hebt tot de volledige broncode. Idealiter via een repository zoals GitLab of GitHub, inclusief documentatie en ontwerpbestanden. Controleer ook of er geen cruciale onderdelen draaien op accounts van de leverancier. Alles wat je nodig hebt om zelfstandig verder te kunnen, moet beschikbaar zijn.

Hetzelfde geldt voor content en data. Die zijn van jou (of je gebruikers) en dat moet glashelder zijn. Neem het expliciet op in de overeenkomst om discussie te voorkomen. Denk ook aan de naam van je applicatie of domein: als dat een merkwaarde vertegenwoordigt, is het belangrijk dat jij daar de rechten van hebt.

Hosting en infrastructuur: waar draait je applicatie?

Zodra je applicatie klaar is, moet hij ergens draaien. Het kiezen en inrichten van de juiste hosting en infrastructuur is dan een cruciale stap. Want een prachtig ontworpen applicatie die hapert door trage servers of onveilige instellingen doet alsnog afbreuk aan de gebruikerservaring.

De inrichting van je hostingomgeving hangt af van wat je applicatie nodig heeft. Verwacht je veel piekbelasting, bijvoorbeeld bij inschrijvingen of ticketverkoop? Dan moet het systeem daarop voorbereid zijn, bijvoorbeeld met autoscaling of load balancing. Heb je koppelingen met interne systemen? Dan kunnen veilige verbindingen of VPN’s nodig zijn.

Draait de applicatie 24/7? Dan zijn monitoring, back-ups en failovervoorzieningen belangrijk. Je wilt bij een storing snel kunnen schakelen, zonder dataverlies of lange downtime.

Zelf hosten of uitbesteden?

Sommige organisaties kiezen ervoor om de hosting uit te besteden aan het ontwikkelbureau. Veel bureaus, zoals Emble, bieden managed hosting aan die optimaal is afgestemd op de gebruikte technologie. Dat heeft als voordeel dat we snel kunnen schakelen als er iets misgaat en dat je één aanspreekpunt hebt.

Zelf hosten is natuurlijk ook mogelijk. Je krijgt dan de applicatie aangeleverd en zorgt zelf voor installatie en beheer. Dat kan prima werken, zeker als je intern de kennis hebt of met een ervaren hostingpartij werkt. Voor bedrijfskritische applicaties raden we in elk geval aan om te zorgen voor een goede SLA en monitoring.

Security en compliance

Beveiliging is geen luxe, zeker niet bij applicaties met persoonlijke of gevoelige gegevens. Kies voor een hostingpartij die voldoet aan standaarden als ISO27001. Let op zaken als versleuteling van verbindingen, veilige opslag en datalokatie binnen de EU (in verband met de AVG).

Werk je met externe diensten of opslag? Controleer dan goed waar je data terechtkomt. Staat het in Europa of in de VS? Dat kan juridisch gezien uitmaken. Houd ook rekening met regels zoals de European Accessibility Act of privacywetgeving.

Performance en uptime

Maak afspraken over wat je mag verwachten. Denk aan laadtijden, beschikbaarheid (uptime) en back-upbeleid. Veel organisaties hanteren minimaal 99,9% uptime. Dat klinkt hoog, maar vraagt om een robuuste infrastructuur. Vraag ook hoe vaak er back-ups worden gemaakt en of het herstelproces is getest. Je wilt niet pas bij een incident ontdekken dat er iets ontbreekt.

Welke maatwerkpartner kies je?

Je hebt inmiddels een goed beeld van wat er allemaal komt kijken bij het ontwikkelen van een maatwerkapplicatie. Het is geen standaardklus. Je hebt te maken met strategie, ontwerp, techniek, beveiliging, doorontwikkeling en niet te vergeten: de eindgebruiker. Je hoeft dat gelukkig niet allemaal zelf te doen maar het maakt de keuze voor de juiste ontwikkelpartner wel des te belangrijker. Waar let je op bij het kiezen van een maatwerkpartner?

Er zijn een aantal punten waarop je kunt letten als je partijen vergelijkt:

• Ervaring met soortgelijke projecten: Heeft de partij al eerder applicaties gebouwd die lijken op wat jij nodig hebt? En in welke sectoren? Bekijk cases, vraag naar voorbeelden of bel eens met een referentie.
• Technische aanpak en stack: Werken ze met bewezen technologie? Open source? En hoe zit het met zaken als versiebeheer, documentatie, testen en security?
• Begrip van jouw context: Begrijpen ze jouw sector, de regelgeving of de dynamiek van jouw organisatie? Hoe goed kunnen ze meedenken?
• Manier van samenwerken: Is er een vast team? Heb je direct contact met ontwikkelaars? Hoe ziet het proces eruit? En hoe worden keuzes gemaakt?
• Visie op doorontwikkeling: Wat gebeurt er ná livegang? Is er ruimte voor optimalisatie? Bieden ze support of onderhoudscontracten? En hoe snel kun je schakelen?
• Toegankelijkheid en beveiliging: Zeker bij publieke of bedrijfskritische applicaties is het belangrijk dat een bureau op de hoogte is van WCAG, AVG en beveiligingsstandaarden.

Bij Emble werken we sinds 2001 aan maatwerkapplicaties voor onderwijs, overheid en het bedrijfsleven. We bouwen bijvoorbeeld het UvA JobBoard, intranetten voor PBL en UWV, en kennisplatforms zoals SWOV en KennisOverZien. Projecten waar inhoud, techniek en gebruikers centraal staan.

We werken met moderne open-source technologie zoals Drupal, Laravel en React. Niet omdat het ‘hip’ is, maar omdat het je als opdrachtgever flexibiliteit en onafhankelijkheid geeft, je zit niet vast aan licenties of aan één leverancier.

Vanuit ons team begeleiden we het hele traject: van strategie en design tot realisatie en beheer. Ook na oplevering blijven we betrokken met support, updates en doorontwikkeling. Korte lijnen, vaste mensen, en de inhoud altijd voorop.

Of je nou met Emble werkt of een andere partij kiest: neem de tijd om kritisch te vergelijken. Plan een kennismaking, stel vragen over hun werkwijze, en kijk of er een klik is.

Conclusie: met de juiste voorbereiding creëer je succes

Zoals je hebt kunnen lezen is een maatwerkapplicatie laten ontwikkelen geen kleinigheid. Het vraagt om visie, duidelijke doelen en een betrouwbare partner. In dit artikel heb je gelezen waar je allemaal op moet letten, van strategie tot techniek, van budgetbewaking tot hosting en eigendom.

Ook ontwikkelingen zoals no-code en AI kwamen voorbij. Hopelijk heb je hiermee veel vragen beantwoord gekregen en misschien ook nieuwe inzichten opgedaan. Maatwerksoftware kan je organisatie echt verder helpen. Mits je het goed aanpakt, stap voor stap. Met focus op wat belangrijk is, ruimte voor feedback en een partner die je begrijpt.

Ben je klaar om die stap te zetten? Dan denken we bij Emble graag met je mee. Of het nu gaat om een slimme tool, een nieuw platform of het verbeteren van je bestaande applicatie, we helpen je graag verder. Heb je vragen naar aanleiding van dit artikel of in het algemeen over het ontwikkelen van een maatwerk applicatie, dan lees en beantwoord ik deze graag in het reactie gedeelte onderaan deze pagina.

Deel dit artikel