Webapplicatie laten ontwikkelen: de ultieme gids 2026

Een webapplicatie laten ontwikkelen is een serieuze strategische zet. Zie het als een verbouwing: je hebt een visie van hoe het moet worden, maar zonder een stevig plan eindig je met een puinhoop en een lege portemonnee.

Veel projecten stranden omdat ze deze eerste, cruciale fase overslaan. Een briljant idee is namelijk pas het begin. De echte kunst is om dat idee te vertalen naar een concrete oplossing voor een écht, urgent probleem. Wij geloven dat dit begint met een diep begrip van je doelgroep en een scherpe strategie, nog voordat er een regel code geschreven wordt.

Van een goed idee naar een kansrijke webapplicatie

Elke succesvolle webapplicatie begint met het oplossen van een pijnlijk duidelijk probleem. Voordat je ook maar één regel code laat schrijven, moet je de realiteit onder ogen zien. Veel ondernemers zijn verliefd op hun eigen concept, maar vergeten de belangrijkste vraag: wie zit hier écht op te wachten?

Het resultaat? Een prachtig gebouwde app die niemand gebruikt. Een oplossing op zoek naar een probleem.

Definieer het probleem en je doelgroep

Focus je op de probleem-oplossing fit. Welk specifiek, urgent pijnpunt los je op? Zonder een vlijmscherp antwoord op die vraag, bouw je op los zand.

Denk dus niet: "Ik wil een app voor de horeca." Denk liever: "Hoe help ik restauranteigenaren in de drukke binnenstad van Eindhoven om hun personeelsplanning efficiënter te maken, zodat ze 10% minder tijd kwijt zijn aan administratie?"

Die specificiteit is alles. Voor een B2B-bedrijf in de Brainport-regio kan het probleem liggen in het stroomlijnen van complexe toeleveringsketens. Door diep in de wereld van je doelgroep te duiken, ontdek je waar de échte frustraties en kansen liggen.

Een webapplicatie is geen doel op zich. Het is een gereedschap om een urgent probleem op te lossen. De waarde zit niet in de techniek, maar in de relevantie voor jouw specifieke gebruiker.

Een grondig customer journey onderzoek is hierbij geen luxe, maar een noodzaak. Het legt precies bloot waar de pijn zit in het huidige proces van je klant.

Valideer je idee voordat je investeert

Voordat je een ontwikkelpartner inschakelt, kun je zelf al ontzettend veel doen om je idee te toetsen. Dit verkleint je risico en maakt je businesscase ijzersterk. Het is de fundering onder je verbouwing.

Een paar manieren om dit slim aan te pakken:

• Praat met mensen. Ga de boer op. Interview potentiële gebruikers, maar vraag niet of ze je product willen kopen. Vraag hoe ze hun werk nu doen, waar ze tegenaan lopen en wat hen 's nachts wakker houdt.
• Bouw een simpele landingspagina. Beschrijf je concept, schets de oplossing en vraag bezoekers om hun e-mailadres achter te laten. Dit is de meest eerlijke manier om interesse te meten.
• Maak een klikbaar prototype. Een tool als Figma is goud waard. Je kunt een visueel prototype maken dat je concept tot leven brengt. Hiermee haal je veel directere en concretere feedback op dan met alleen een verhaal.

Deze vroege validatie is onbetaalbaar. Je voorkomt er kostbare misstappen mee en stapt het ontwikkeltraject in met een plan dat niet alleen gebaseerd is op aannames, maar op bewijs. Zo wordt de samenwerking met een strategische partner zoals wij bij Koll&Burg Design veel waardevoller. We kunnen dan direct de merkstrategie verweven met een functionele behoefte waarvan we weten dat die echt bestaat.

De blauwdruk: wat moet je webapplicatie kunnen?

Oké, het idee staat. De markt heeft gesproken. Nu begint het echte werk: van een ruwe schets naar een messcherpe blauwdruk. Dit is het moment waar je bepaalt wat je webapplicatie precies moet kunnen. En, misschien nog wel belangrijker, wat bewust niet.

Zonder een strak plan sluipt er onvermijdelijk ‘scope creep’ in. Het project wordt een bodemloze put van ‘leuke extraatjes’. Je verliest focus, het budget explodeert en de deadline vervaagt. Jouw blauwdruk is je beste verdediging. Je eerste filter.

Prioriteiten stellen: de MoSCoW-methode

Een ijzersterke techniek om je wensenlijst te temmen is de MoSCoW-methode. Het is een botte, maar eerlijke manier om keuzes te maken. Het dwingt je om de essentie van de bijzaken te scheiden.

Het werkt zo:

• Must-haves: De niet-onderhandelbare kern. Zonder dit is je app simpelweg kapot. Denk aan de mogelijkheid om een datum te kiezen en te betalen in een boekingssysteem. Valt dit weg, dan stort alles in.
• Should-haves: Belangrijk, maar niet cruciaal voor dag één. Ze maken de ervaring compleet. Een automatische herinneringsmail voor een boeking is een perfect voorbeeld. De app werkt zonder, maar is veel beter mét.
• Could-haves: De ‘nice-to-haves’. Leuk als er tijd en budget over is, maar ze lossen geen kernprobleem op. Denk aan de optie om een favoriete tafel in een restaurant te kiezen. Het voegt flair toe, geen fundamentele waarde.
• Won't-haves (this time): Alles wat je bewust niet gaat bouwen. Dit is misschien wel de belangrijkste categorie. Het creëert rust en focus. Door helder te zijn over wat je uitsluit, bewaak je de grenzen van je project.

Deze methode is geen invuloefening. Het is een strategische discussie die de basis legt voor een realistisch, gefaseerd plan. Essentieel om je planning en budget in de hand te houden.

User stories: vertaal wensen naar de praktijk

Een lijst met functies is abstract. Om ze tot leven te brengen, giet je ze in user stories: korte, glasheldere verhaaltjes vanuit het perspectief van je gebruiker. Het format is simpel: "Als een [gebruiker], wil ik [een actie uitvoeren], zodat ik [een doel bereik]."

Voor een B2B-platform in de horeca kan dat zijn: “Als een restaurantmanager, wil ik met één klik de allergeneninformatie van een leverancier kunnen downloaden, zodat ik direct kan voldoen aan de wettelijke eisen.”

Dit is de kracht van een user story. Het maakt de ‘waarom’ achter de functie pijnlijk duidelijk. Iedereen, van de directiekamer tot het dev-team, snapt wat er gebouwd wordt en voor wie. Geen ruimte voor misverstanden. De technologie staat altijd in dienst van de mens. Vang je de aandacht van die mens nog niet? Lees dan onze uitleg over wat een goede landingspagina maakt.

De kracht van een Minimum Viable Product (MVP)

De MoSCoW-methode leidt je bijna vanzelf naar de kern: je Minimum Viable Product (MVP). Dit is de meest uitgeklede versie van je applicatie die nog steeds échte waarde levert aan je eerste gebruikers. Het is de optelsom van je ‘must-haves’, aangevuld met misschien een enkele ‘should-have’. Meer niet.

Een MVP is geen halfbakken product. Het is een klein, maar compleet en werkend product. Het doel is niet om alles te bouwen, maar om zo snel mogelijk te leren van echte gebruikers.

Voor ambitieuze bedrijven in een dynamische regio als Brainport Eindhoven is de MVP-aanpak geen luxe, maar een noodzaak. Je minimaliseert het risico, verkort je time-to-market en krijgt direct feedback uit de praktijk.

In plaats van jaren te bouwen aan een visie in een ivoren toren, lanceer je een eerste, vlijmscherpe oplossing voor het meest urgente probleem. Vanaf daar bouw je verder. Iteratief, gedreven door data, niet door aannames. Dat maakt je wendbaar, slim en verhoogt je slagingskans exponentieel.

De juiste technologie kiezen: het fundament van je app

De technologie achter je webapplicatie is als de fundering van een huis. Je ziet het niet, maar het bepaalt alles: de stabiliteit, de veiligheid en hoe makkelijk je later kunt uitbouwen. Een verkeerde keuze vandaag betekent later kostbare verbouwingen of zelfs sloop. De techniek, de 'tech stack', klinkt misschien ingewikkeld, maar de kern is te begrijpen. En door de juiste vragen te stellen, zorg je ervoor dat je een app bouwt die meegroeit, in plaats van na een jaar al kraakt en piept.

Een webapplicatie heeft grofweg drie onderdelen die perfect moeten samenwerken: de voorkant, de achterkant en het geheugen.

De machinekamer van je applicatie

De tech stack is de combinatie van programmeertalen en tools. Zie het als de materiaalkeuze voor je huis: bouw je met beton en staal voor een wolkenkrabber, of met hout voor een flexibel tuinhuis?

• Front-end: Dit is alles wat de gebruiker ziet en aanraakt. De knoppen, de menu’s, de hele beleving. Frameworks als React of Vue.js zijn hier populair omdat ze zorgen voor een snelle, soepele interface waar mensen graag mee werken.
• Back-end: De onzichtbare motor. Hier gebeurt de magie: data wordt verwerkt, berekeningen worden gemaakt en de logica draait. Populaire keuzes zijn bijvoorbeeld Node.js, PHP (vaak met het Laravel framework) of Python.
• Database: Het digitale archief. Hier wordt alle data – van gebruikersprofielen tot bestellingen – veilig opgeslagen. Denk aan systemen als MySQL, PostgreSQL of MongoDB.

De beste combinatie hangt af van je ambities. Een goede ontwikkelpartner zal je hierin adviseren zonder je te verdrinken in jargon. Ze leggen uit waarom een bepaalde keuze slim is voor jouw specifieke doel.

Slimme verbindingen met API's

Een webapplicatie is zelden een eiland. De échte kracht ontstaat pas als je hem naadloos verbindt met de systemen die je al gebruikt. Dit gebeurt via een API (Application Programming Interface), een soort digitale stekkerdoos die software met elkaar laat praten.

Denk eens aan de efficiëntie die dit oplevert:

• Een nieuwe lead uit je app schiet automatisch je CRM-systeem in. Geen overtypen meer.
• Na een bestelling wordt de factuur direct aangemaakt in je boekhoudsoftware.
• Klanten rekenen soepel en veilig af via een koppeling met Mollie of Stripe.
• Voor een restaurant in de regio Eindhoven kan een koppeling tussen de online reserveringstool en het kassasysteem in de zaak goud waard zijn.

Deze integraties voorkomen dubbel werk, verkleinen de kans op fouten en maken je bedrijfsvoering simpelweg slimmer. Zeker wanneer je veel met data werkt, bijvoorbeeld bij het opzetten van server-side tagging, is een feilloze data-uitwisseling cruciaal. Wil je daar dieper induiken, lees dan ons artikel over wat server-side tagging is.

Een toekomstbestendige architectuur gaat niet over de nieuwste hype. Het gaat over het bouwen van een flexibel systeem dat meebeweegt met de groei van je bedrijf en de wensen van je klanten.

Een ervaren partner denkt hierin vooruit. Ze bouwen niet alleen de functie die je nu vraagt, maar leggen een fundament waarop je over twee jaar moeiteloos een nieuwe verdieping kunt bouwen. Die investering in een schaalbare architectuur betaalt zich keer op keer terug, omdat je niet voor elke nieuwe feature de hele boel hoeft open te breken.

Wat kost een webapplicatie laten ontwikkelen?

Oké, de hamvraag. De vraag die altijd als eerste op tafel komt: wat gaat zo’n webapplicatie eigenlijk kosten? Het antwoord is nooit een simpel getal. Er is geen menukaart, want de investering hangt volledig af van de diepgang, de complexiteit en de partner die je kiest.

Het verschil tussen een compacte MVP en een complexe, op maat gemaakte oplossing die het kloppend hart van je bedrijf wordt, is enorm. Laten we de mist optrekken en kijken naar realistische kosten en prijsmodellen.

Fixed price of nacalculatie?

Als je offertes opvraagt, kom je meestal twee smaken tegen. De keuze hiertussen zegt veel over de zekerheid die je zoekt en de flexibiliteit die je nodig hebt.

• Fixed Price (vaste prijs): Hier spreek je vooraf een vaste prijs af voor een strak afgebakende scope. Ideaal als je een MVP laat bouwen waarvan de ‘must-haves’ in steen gebeiteld zijn. Het geeft budgettaire zekerheid. De keerzijde? Elke aanpassing of nieuw inzicht buiten de scope betekent meerwerk en dus extra kosten. Het is weinig flexibel.
• Time & Material (nacalculatie): Je betaalt voor de uren die het team daadwerkelijk maakt. Dit model is perfect voor complexe, langlopende projecten waarbij je wendbaar wilt blijven. De scope kan en mag evolueren. Het vraagt wel om blind vertrouwen in je partner en strakke, transparante communicatie om het budget in de gaten te houden.

Voor veel projecten die agile worden aangepakt, werkt een hybride model het best. Een vaste prijs voor de fundering (de MVP) en nacalculatie voor de doorontwikkeling en verfijning.

Wat kost het nou écht?

Hoewel elke applicatie uniek is, kunnen we je wel een idee geven van de investering. Deze indicaties zijn gebaseerd op de gangbare Nederlandse uurtarieven, die meestal tussen de €80 en €150 liggen.

• Eenvoudige MVP (Minimum Viable Product): Denk aan een interne tool voor een MKB-bedrijf in de Brainport-regio met een paar kernfuncties. Kostenindicatie: €15.000 – €40.000.
• Gemiddelde maatwerk webapplicatie: Een applicatie met verschillende gebruikersrollen, koppelingen met andere software (API’s) en een volledig eigen design. Kostenindicatie: €40.000 – €80.000.
• Complexe enterprise applicatie: Een bedrijfskritische applicatie met ingewikkelde logica, meerdere externe koppelingen en de hoogste eisen aan veiligheid en performance. Kostenindicatie: Vanaf €80.000+.

Het werk wordt verdeeld over verschillende technische lagen, die elk hun eigen expertise vereisen.

Zoals je ziet, zit er zowel aan de voorkant (front-end), de achterkant (back-end) als in de data (database) flink wat werk, wat de totale kosten beïnvloedt.

Voor een wat eenvoudigere webapplicatie moet je in Nederland rekenen op een doorlooptijd van 2 tot 4 maanden. Dat is een realistische tijdlijn voor veel startups en scale-ups in bijvoorbeeld de Brainport-regio die snel een eerste versie live willen hebben. Voor een horecazaak in Eindhoven kan dit een reserveringssysteem zijn dat direct tijd en fouten bespaart.

Reken voor zo’n project op een budget tussen de €20.000 en €50.000. Zorg er dan wel voor dat je de branding vanaf het begin goed integreert. Het voorkomt dat je later alles weer moet omgooien.

De kosten van een applicatie staan nooit op zichzelf. Het is een investering in je toekomst, net zoals je merk dat is. Wil je een breder beeld krijgen van wat erbij komt kijken als je software laten maken overweegt? En ben je ook benieuwd naar de kosten van een merkfundament? Lees dan onze gids over wat branding kost.

Het ontwikkelproces: van sprint tot lancering

Oké, de plannen zijn gesmeed, de techniek is gekozen en het budget staat vast. Nu begint het echte werk: de bouw van je webapplicatie. Dit is geen fase waarin je achteroverleunt en wacht tot het af is. Integendeel. Juist nu is jouw rol als opdrachtgever cruciaal. Een proactieve, scherpe samenwerking maakt het verschil tussen een 'oké' applicatie en een product dat écht impact maakt.

Moderne ontwikkelteams, zeker in een innovatieve regio als Brainport, werken bijna altijd volgens de agile-methode. Zie het niet als een vage term, maar als een ritme. Het project wordt opgedeeld in korte, behapbare stukken: sprints.

Werken in sprints: het ritme van vooruitgang

Een sprint duurt meestal twee weken en heeft één helder doel: een klein, werkend stukje van je applicatie opleveren. Dit vaste ritme brengt focus en voorspelbaarheid. Het voorkomt het horrorscenario waarbij een project maandenlang onder de radar verdwijnt en je bij de oplevering voor vervelende verrassingen komt te staan.

Jouw rol hierin? Je bent geen toeschouwer, maar een actieve speler.

• Sprint planning: Voor elke sprint begint, bepaal je samen met het team welke taken (user stories) van de wensenlijst worden opgepakt. Jouw inzicht in de business bepaalt de prioriteiten. Zonder jouw sturing wordt er misschien wel gebouwd, maar niet per se aan wat het belangrijkst is.
• Daily stand-ups: Dit zijn korte, dagelijkse check-ins (meestal maar 15 minuten) waarin het team de voortgang, plannen en obstakels bespreekt. Je hoeft er niet altijd bij te zijn, maar zorg dat je bereikbaar bent. Eén snelle vraag van een developer kan een dag vertraging voorkomen.
• Sprint demo: Aan het einde van de sprint laat het team zien wat er is gebouwd. Dit is jouw belangrijkste moment. Hier zie en test je de nieuwe functionaliteit en geef je direct feedback.

Effectief feedback geven en koers houden

De sprint demo is waar jouw input het meeste waard is. Wees voorbereid. Geef concrete, opbouwende feedback die gericht is op de functie. "Ik vind het niet mooi" is lastig, maar "Deze knop is onvindbaar voor een nieuwe gebruiker" is goud waard.

Om dit proces overzichtelijk te houden, gebruiken teams tools als Jira, Asana of Trello. Hierin vind je de complete takenlijst (de backlog), de planning per sprint en kun je op een gestructureerde manier feedback en bugs doorgeven.

Goede samenwerking is tweerichtingsverkeer. Wees bereikbaar, geef snelle en heldere feedback en vertrouw op de expertise van het team. Zo bouw je momentum en houd je de vaart in het project.

Goede, open communicatie is de motor van een succesvol project. Als je op zoek bent naar een partner die dat snapt, kijk dan eens hoe een creatief bureau in Eindhoven zoals het onze dit aanpakt. Wij geloven in een radicale transparantie, van de eerste schets tot de laatste test.

Testen, testen en nog eens testen

Terwijl de applicatie groeit, wordt testen steeds belangrijker. Een applicatie die niet door en door is getest, is onbetrouwbaar en kan je reputatie flink schaden. Zie testen niet als een sluitpost, maar als een integraal onderdeel van kwaliteit. Het is de fundering van vertrouwen.

Verschillende tests vullen elkaar aan en zorgen samen voor een robuust resultaat:

• Unittests: De developers testen de kleinste, losse bouwstenen van de code.
• Integratietests: Hier wordt gecontroleerd of al die losse bouwstenen goed met elkaar ‘praten’.
• Gebruikerstesten (UAT): Dit is de ultieme realiteitscheck. Jij, je team en een selecte groep eindgebruikers gaan de applicatie gebruiken zoals hij bedoeld is. Werkt het in de praktijk? Is het logisch?
• Securitytests: Een specialist probeert bewust ‘in te breken’ in de applicatie om zwakke plekken in de beveiliging op te sporen voordat kwaadwillenden dat doen.

Klaar voor de lancering: deployment en hosting

Als alle lichten op groen staan, is het moment van de waarheid daar: de livegang, ofwel ‘deployment’. Dit is veel meer dan een druk op de knop. Het vereist een stabiele en veilige serveromgeving die klaar is voor jouw gebruikers.

De keuze voor hosting is hierin allesbepalend. Ga je voor een gedeelde server of een eigen, dedicated machine? Of kies je voor een flexibele cloudoplossing zoals Amazon Web Services (AWS) of Google Cloud Platform? Die laatste optie is ideaal voor applicaties die moeten kunnen meegroeien of wisselende bezoekersaantallen hebben.

Je ontwikkelpartner kan je precies adviseren wat past bij jouw ambities, veiligheidseisen en budget. Een professionele lancering omvat ook het instellen van monitoring, zodat problemen direct worden gesignaleerd en opgelost, vaak nog voordat je er zelf iets van merkt.

Na de lancering: onderhoud en doorontwikkeling

Gefeliciteerd, je applicatie is live. Een enorme mijlpaal, maar het echte werk begint nu pas. Want een applicatie die stilstaat, is in feite al aan het verouderen. Zie de lancering niet als de finish, maar als het startschot.

Het is nu zaak om je digitale investering te beschermen en te laten groeien. Dat doe je met een ijzersterk plan voor onderhoud en een heldere visie voor de toekomst.

Onderhoud is geen kostenpost, maar je verzekering

Je applicatie draait op software, en die software heeft constant aandacht nodig. Updates voor de server, de programmeertaal, de frameworks… het is een oneindige stroom. Dit negeren is geen optie. Het is de snelste route naar beveiligingslekken en een trage, frustrerende gebruikerservaring.

Om dit goed te regelen, sluit je een Service Level Agreement (SLA) af met je partner. Dit contract is je verzekering voor continuïteit. Het legt vast wat er gebeurt als er iets misgaat, maar belangrijker nog: het zorgt ervoor dat veel problemen worden voorkomen.

Een solide SLA dekt minimaal:

• Preventief onderhoud: Proactief installeren van security patches en updates, voordat ze een probleem worden.
• Monitoring: 24/7 bewaking van de servers en de applicatie om problemen direct op te sporen.
• Bug fixing: Gegarandeerde reactietijden voor het oplossen van onvermijdelijke foutjes in de software.
• Back-ups: Regelmatige, veilige kopieën van alles, zodat je bij een calamiteit snel weer in de lucht bent.

Een SLA is geen ‘extraatje’. Het is een fundamentele investering in de betrouwbaarheid en veiligheid van een bedrijfskritische tool. Het geeft je de rust dat je digitale motor soepel en veilig blijft draaien.

Van data naar een levende roadmap

Een live applicatie is een goudmijn aan inzichten. Je ziet nu eindelijk hoe échte mensen je product gebruiken, waar ze vastlopen en welke functies ze omarmen. Het is cruciaal om deze feedback niet te laten verdampen, maar te gebruiken als brandstof voor de volgende stap.

Zet een systeem op om deze inzichten structureel te verzamelen. Denk aan:

• Webanalytics: Tools als Google Analytics 4 of Matomo laten genadeloos zien waar gebruikers afhaken en welke routes populair zijn.
• Gebruikersfeedback: Een simpele feedbackknop of een periodieke enquête kan wonderen doen. Vraag direct wat ze missen of wat beter kan.
• Support tickets: De vragen die bij je klantenservice binnenkomen, zijn de puurste vorm van feedback. Ze leggen bloot wat onduidelijk is of ontbreekt.

Al deze inzichten vormen de basis voor je product roadmap. Door deze te combineren met je eigen zakelijke visie, creëer je een concreet plan. Zo bouw je geen losse features, maar werk je stap voor stap aan een steeds waardevollere applicatie die meegroeit met je gebruikers en je bedrijf.

De meest gestelde vragen, beantwoord

Je staat op het punt een serieuze stap te zetten. Dan komen er ongetwijfeld vragen op. Hier geven we antwoord op de vragen die we het vaakst horen in gesprekken – helder en zonder omwegen.

Wat is nou het verschil tussen een webapplicatie en een website?

Een website kun je zien als een digitale folder: hij zendt informatie. Een webapplicatie is een stuk gereedschap; hij doet iets.

Een website vertelt wie je bent, een webapplicatie laat je klanten of team iets doen. Denk aan een projectmanagementtool, een online boekingensysteem voor je horecazaak in Eindhoven, of een klantportaal waarmee je B2B-klanten zelf hun orders beheren. Het is interactief, niet passief.

Is een native app uit de App Store niet veel beter?

Niet per se. Die vraag is eigenlijk: wat moet het kunnen? Een web app laten maken draait direct in elke browser, op elke telefoon of laptop. Dat maakt de ontwikkeling sneller, goedkoper en het onderhoud een stuk eenvoudiger. Geen gedoe met app stores.

Een native app is pas echt zinvol als je diep in de hardware van een telefoon moet duiken. Denk aan geavanceerd cameragebruik, de gyroscoop voor beweging, of specifieke pushnotificaties die dieper gaan dan de standaard. Voor 9 van de 10 ideeën is een webapplicatie de slimmere, flexibelere keuze.

Kan ik de applicatie later nog uitbreiden?

Absoluut. Sterker nog, dat is juist de bedoeling. Een goed gebouwde webapplicatie is geen afgerond product, maar een startpunt. De architectuur moet schaalbaar zijn, wat simpelweg betekent dat we er later makkelijk nieuwe functies aan kunnen toevoegen.

Dit is precies waarom we vaak starten met een Minimum Viable Product (MVP). We bouwen de kern, de absolute essentie. Die lanceer je, test je in de praktijk en op basis van echte gebruikersdata bouw je gericht verder. Dat houdt je wendbaar en voorkomt dat je investeert in functies die niemand gebruikt.

Heeft jouw bedrijf in de regio Eindhoven een uniek idee voor een webapplicatie die naadloos aansluit op je merk? Bij Koll&Burg Design denken we strategisch met je mee, van concept tot een feilloze integratie in je brand identity. Kom langs op de Prins Hendrikstraat 1 in hartje Eindhoven, neem contact op via wi****@**************gn.com of bel +31(0)6 14432083 om de mogelijkheden te bespreken.