Question 1

Hoe is deze website gebouwd?

Accepted Answer

Deze website is gebouwd met Next.js (React) en TypeScript. De site is volledig op maat ontwikkeld, met server-side rendering voor snelle laadtijden en goede SEO. Voor de vormgeving gebruik ik Tailwind CSS, zodat styling consistent en onderhoudbaar blijft.

Question 2

Hoe zit het met je beschikbaarheid

Accepted Answer

Ik ben beschikbaar voor projecten maar niet fulltime. Neem contact met me op voor exacte details. Ik kan zowel remote als op locatie werken.

Question 3

Welk uurtarief hanteer je?

Accepted Answer

Ik hanteer een verschillende uurtarieven voor verschillende diensten i.v.m. ervaring en het aantal uur dat er in een opdracht gaat zitten.

In kleine online marketing opdrachten van minder dan 4 uur werk gaat relatief veel tijd zitten in zaken die ik niet in rekening kan brengen.

In dat geval reken ik een uurtarief van €85,-. In andere gevallen het standaardtarief van €75,-.

In development werk gaat in de regel wat meer tijd zitten. In dit geval reken ik €65,-

De uitzondering hierop zijn kleine werkzaamheden via een strippenkaart voor onderhoud. Die worden voor een gereduceerd tarief van €60,- aangeboden op basis van best effort..

Question 4

Doe je ook het ontwerp (design) van een website?

Accepted Answer

Ik ben geen grafisch ontwerper en heb ook geen opleiding grafische vormgeving gevolgd. Wat ik wel doe, is bestaande ontwerpen aanpassen en er een mooie, functionele website van maken. Voor het volledig ontwerpen van een grafisch ontwerp werk ik samen met ervaren vormgevers, zodat u altijd een professioneel resultaat krijgt.

Question 5

Werk je ook whitelabel?

Accepted Answer

U kunt mij ook inhuren voor uw bureau. Hierbij kan ik geheel whitelabel of onder uw naam deze werkzaamheden voor uw klanten uitvoeren.

Question 6

Hoe beïnvloedt een JavaScript-framework de SEO van mijn webapplicatie?

Accepted Answer

Het gebruik van een JavaScript-framework kan invloed hebben op hoe zoekmachines uw webapplicatie indexeren. Voor applicaties die achter een login zitten, speelt dit meestal geen rol, omdat deze content niet openbaar is en dus niet geïndexeerd hoeft te worden. Voor openbare applicaties die goed vindbaar moeten zijn, is het verstandig om het framework te combineren met server-side rendering (SSR). Bij alleen client-side rendering (CSR) ziet de Googlebot initieel vaak een blanco pagina, omdat de content pas door de browser wordt opgebouwd. Dit kan ervoor zorgen dat de website niet volledig of correct wordt geïndexeerd, wat de vindbaarheid schaadt. Met SSR wordt de pagina volledig door de server opgebouwd voordat deze naar de gebruiker en zoekmachines wordt gestuurd, waardoor content direct beschikbaar is voor indexering en de SEO-prestaties verbeteren.
Daarnaast biedt een JavaScript-framework veel voordelen voor het bouwen van complexe, interactieve interfaces. Componenten kunnen hergebruikt worden, de frontend kan los van de backend ontwikkeld worden, en de applicatie blijft flexibel en toekomstbestendig. Frameworks zoals Nuxt.js en Next.js voegen daar nog extra voordelen aan toe, zoals automatische optimalisatie van metadata, eenvoudige routing van pagina’s, snellere laadtijden doordat de eerste paginaweergave door de server wordt gerenderd, en mogelijkheden voor statische sitegeneratie die performance en caching verbeteren.
Er zijn echter ook enkele aandachtspunten bij SSR. De applicatie moet bijvoorbeeld draaien op een Node.js-server of een vergelijkbare omgeving, en caching en performance-optimalisaties moeten goed worden ingesteld om serverbelasting te beperken. Ook kan de initiële ontwikkeltijd iets langer zijn door de configuratie en setup van SSR waardoor dit vooral zich leent voor applicaties die niet achter een login verborgen zijn en geindexeerd moeten worden.
Kortom, een JavaScript-framework in combinatie met server-side rendering biedt uitstekende SEO-mogelijkheden, betere performance en flexibiliteit, waardoor uw webapplicatie goed voorbereid is op groei en toekomstige uitbreidingen.

Question 7

Waarom kiezen voor een JavaScript-framework boven traditionele HTML?

Accepted Answer

Een webapplicatie kan worden opgebouwd met traditionele HTML-pagina’s, wat vaak voldoende is voor eenvoudige of statische websites. Voor moderne, interactieve applicaties biedt een JavaScript-framework echter duidelijke voordelen.
Een van de grootste voordelen is dat pagina’s niet telkens volledig hoeven te worden herladen bij interacties of updates. Hierdoor voelt de webapplicatie veel reactiever en sneller aan voor de gebruiker. Real-time updates, interactieve dashboards en complexe navigatie werken vloeiender, waardoor de ervaring vergelijkbaar is met een native applicatie.
Het gebruik van een JavaScript-framework kost initieel ongeveer 30% meer ontwikkeltijd dan het bouwen met alleen HTML, omdat de structuur, componenten en build-tools opgezet moeten worden. Voor complexere applicaties betaalt dit zich echter terug: functies kunnen hergebruikt worden, onderhoud is eenvoudiger en uitbreidingen kunnen sneller worden doorgevoerd. Bovendien maakt een framework het eenvoudiger om frontend en backend te scheiden, waardoor toekomstige uitbreidingen, integraties of zelfs een mobiele app eenvoudiger zijn.
Kortom: traditionele HTML is prima voor eenvoudige toepassingen, maar een JavaScript-framework maakt uw webapplicatie interactiever, sneller en toekomstbestendig, terwijl het de ontwikkeling en het onderhoud op de lange termijn efficiënter en flexibeler maakt.

Question 8

Wat zijn de voordelen van een gescheiden frontend en backend voor flexibiliteit?

Accepted Answer

Bij kleinere webapplicaties worden frontend en backend vaak in één systeem ontwikkeld. Dit kan prima werken, vooral als er geen complex JavaScript-framework nodig is en de frontend bestaat uit eenvoudige HTML-pagina’s, vergelijkbaar met een website. Voor kleinere projecten is dit vaak de snelste en meest directe aanpak.

Bij grotere webapplicaties of applicaties die in de toekomst verder moeten worden doorontwikkeld, is het vaak verstandiger om frontend en backend als aparte applicaties te bouwen. Deze scheiding biedt verschillende belangrijke voordelen:

• Eenvoudiger vervangen of updaten van de frontend: Omdat de frontend losstaat van de backend, kan deze aangepast of vernieuwd worden zonder dat de backend wordt beïnvloed.

• Betere onderhoudbaarheid: Voor complexe projecten wordt het overzichtelijker om aanpassingen en uitbreidingen door te voeren, omdat frontend en backend onafhankelijk van elkaar kunnen worden ontwikkeld en beheerd.

• Vrijheid in technologie: Frontend en backend kunnen in totaal verschillende technologieën worden ontwikkeld, zonder dat het gekozen framework beperkingen oplegt. Zo kan de frontend bijvoorbeeld moderne gebruikerservaringen bieden, terwijl de backend draait op robuuste en schaalbare systemen.

• Toekomstbestendig: Een gescheiden architectuur maakt het makkelijker om nieuwe functionaliteiten toe te voegen of de applicatie te integreren met andere systemen. Zo kan bijvoorbeeld later een mobiele app worden toegevoegd zonder dat er veel aanpassingen nodig zijn aan de bestaande backend.

Kortom: het loskoppelen van frontend en backend levert flexibiliteit, schaalbaarheid en onderhoudsgemak op, waardoor uw webapplicatie beter voorbereid is op groei, toekomstige veranderingen en uitbreiding naar andere platformen.

Question 9

Kan ik kosten besparen door een bestaand webapplicatie-template te gebruiken?

Accepted Answer

Een groot deel van de ontwikkeltijd van een webapplicatie kan gaan zitten in het uitwerken van een grafisch ontwerp naar HTML of een JavaScript-framework zoals React of Vue. Dit geldt zelfs als we hiervoor AI-tools gebruiken om repetitief werk te automatiseren. Het gaat hier namelijk puur om de vormgeving, er zit nog geen functionaliteit achter. Het volledig handmatig ontwerpen en omzetten van een op maat gemaakt admin-systeem kan daardoor redelijk wat tijd kosten en uiteraard het budget belasten.

Een efficiëntere manier om te werken is om te starten met een bestaand admin-template. Deze kant-en-klare ontwerpen zijn vaak al geschikt voor veel use cases en zijn volledig uitgewerkt in HTML of in een frontend framework. Door hierop voort te bouwen besparen we veel tijd die anders in puur visueel werk zou gaan zitten. Eventuele ontbrekende onderdelen ontwerpen we specifiek op maat, zodat het resultaat toch uniek blijft.

Door deze aanpak blijft er meer budget over om te investeren in de functionaliteit aan de achterkant van de applicatie. Zo profiteert u van een webapplicatie die zowel snel ontwikkeld als technisch robuust is, met een professioneel ogend design dat binnen uw budget blijft.

Question 10

Welke technologieen gebruik ik voor het bouwen van een webapplicatie

Accepted Answer

Ik kan webapplicaties bouwen met moderne frontend-technologieën zoals React, Vue, Next.js en Nuxt.js, afhankelijk van de wensen en eisen van het project. Voor de backend maak ik gebruik van Laravel of Django, zodat de applicatie robuust, schaalbaar en onderhoudbaar is.
Daarnaast kunnen applicaties binnen containers worden opgezet, waardoor ze eenvoudig schaalbaar zijn en flexibel ingezet kunnen worden bij cloudproviders. Voor extra functionaliteit en performance kan ik gebruikmaken van cloudtechnologieën van Google, zoals Firebase, Firestore, Cloud SQL en BigQuery, zodat data efficiënt wordt beheerd en uw applicatie klaar is voor groei en integraties met andere systemen.
Kortom: door de juiste combinatie van frontend, backend, containers en cloudservices kan uw webapplicatie efficiënt, flexibel en toekomstbestendig worden ontwikkeld.

Question 11

Release cycle

Accepted Answer

Ik werk veelal alleen aan uw applicatie i.p.v. in een scrum team met verschillende rollen. De manier van werken die ik hierbij aanhoud is dat we bijvoorbeeld eens in de twee weken een bespreking hebben welke functionaliteit we willen door ontwikkelen, waarom en hoe. Na het ontwikkelen zal ik een release op een testomgeving doen waar we dit testen en als alles ok is zal die 1x per week worden doorgevoerd.

Question 12

Onderhoud en support aan een webapplicatie

Accepted Answer

Uw webapplicatie zal beheerd en onderhouden moeten worden. Veelal adviseer ik hiervoor een vast aantal uur per maand. Er zullen waarschijnlijk zeker in het begin vragen ontstaan voor dingen die nog niet mogelijk zijn in de applicatie. Ik kan veelal problemen bijvoorbeeld direct in de database oplossen en dan later een feature release doen dat u dit soort zaken later ook zelf kunt aanpassen of inzien. Zodoende kunnen we in de loop der tijd uw applicatie doorontwikkelen.

Question 13

Minimal viable product

Accepted Answer

Meestal heeft u een idee voor een App maar weet u niet 100% zeker hoe uw gebruikers uw applicatie gaan gebruiken, wat ze belangrijk vinden en wat niet. Veel functionaliteit die niet absoluut noodzakelijk is voor de werking van de app kan een grote extra kostenkost zijn. Veelal is het verstandig om met een basis app te beginnen, te zorgen dat die goed werkt.

Na verloop van tijd zal duidelijk worden wat belangrijke features zijn en wat er misschien nog mist. Vanuit dat oogpunt kijken we samen in hoeverre we de app kunnen verbeteren in plaats van op aannames al gelijk vanaf de start beginnen met een hele uitgebreide applicatie.

Webapplicatie laten maken

Offerte aanvragen