Wat is full-stack website ontwikkeling?

Full-stack ontwikkeling betekent dat één persoon of team zowel de voorkant als de achterkant van een website of applicatie bouwt. De hele stapel, van wat de bezoeker ziet tot de database eronder.

Dit artikel gaat over het beroep en over wat je eraan hebt als opdrachtgever. De techniek zelf staat elders: de browserkant bij front-end ontwikkeling en de serverkant bij back-end ontwikkeling.

Wat die stapel precies is

Een stack is de vaste combinatie van onderdelen waarop een project draait. Onderop het besturingssysteem en de webserver, daarboven een programmeertaal, daarnaast een database, en bovenop de code die in de browser draait.

De oudste en meest gebruikte combinatie heet LAMP: Linux, Apache, MySQL en PHP. Vrijwel elke WordPress-site in Nederland draait op een variant daarvan. Wie zich in die wereld full-stack noemt, kent PHP, MySQL, HTML, CSS en JavaScript.

In de wereld van webapplicaties kom je andere combinaties tegen. MEAN en MERN gebruiken van boven tot onder JavaScript, met Node.js op de server en Angular of React in de browser. Het voordeel is dat je in één taal blijft. Het nadeel is dat je alles zelf bouwt wat een systeem als WordPress al voor je heeft.

Welke stapel iemand beheerst zegt dus meer dan het woord full-stack zelf. Iemand die full-stack is in JavaScript kan niet zomaar aan jouw WordPress-site werken, en andersom net zo goed niet.

Waar de term vandaan komt

Vroeger was er geen scheiding. Wie een website maakte deed alles, want er was weinig te doen: een paar pagina's, misschien een formulier.

Toen websites applicaties werden, viel het vak uiteen. De browserkant werd een specialisme met eigen raamwerken en eigen problemen, en de serverkant net zo goed. Ergens rond 2010 kwam de term full-stack developer op om de mensen aan te duiden die beide kanten bleven doen.

Sindsdien is de term flink opgerekt. In vacatures staat hij vaak voor iemand die alles moet kunnen wat er in het bedrijf te doen valt, inclusief servers, ontwerp en klantcontact. Ik zou daar bij het lezen van een vacature of een offerte altijd doorvragen wat er precies mee bedoeld wordt.

Een gewone werkdag

Het beeld van iemand die de hele dag nieuwe dingen bouwt klopt niet. Bij het meeste werk gaat de tijd op aan begrijpen wat er al staat.

Een gewone dag bestaat uit een paar taken door elkaar. Een fout naspeuren die een klant meldde, een bestaand scherm uitbreiden met een veld, een koppeling met een ander systeem aanpassen omdat die partij iets veranderde, en een update draaien die niet mag omvallen.

Het echte vakmanschap zit in het overzicht. Iemand die beide kanten kent, ziet meteen of een traag scherm komt door een zware zoekopdracht op de database of door een afbeelding van vier megabyte. Wie maar één kant kent, gaat aan de verkeerde kant zoeken.

Dat overzicht is ook waar de tijdwinst zit. Een bug die over de grens tussen voorkant en achterkant loopt kost bij twee partijen dagen aan heen en weer praten, en bij één persoon een middag.

Naast programmeren komt beheer

Wie zich full-stack noemt, komt onvermijdelijk uit bij het draaiend houden van het geheel. Dat deel wordt in offertes stelselmatig vergeten.

Het gaat om versiebeheer met git, zodat elke wijziging terug te vinden is en terug te draaien. Om een testomgeving die op de echte lijkt. Om code uitrollen zonder de site plat te leggen. Om back-ups die je ook echt hebt teruggezet. En om in de gaten houden of alles het nog doet, want anders is je klant je meldingssysteem.

Daarbij hoort ook keuzes maken over waar iets draait. Wat een site nodig heeft aan webhosting hangt af van wat erop gebouwd is, en die twee beslissingen los van elkaar nemen levert bijna altijd gedoe op.

Voor kleine projecten is dit gewoon onderdeel van het werk. Bij grotere teams is het een apart vak met een eigen naam, en dan zit er iemand tussen die alleen dit doet.

Moet er een raamwerk in je project?

Dit is de vraag waar opdrachtgevers het minst zicht op hebben en waar de meeste geldverspilling zit.

Een raamwerk als React of Vue is gemaakt voor schermen waarin voortdurend iets verandert zonder dat de pagina opnieuw laadt. Denk aan een planbord, een dashboard of een winkelmand die live meerekent. Daar verdient het zich terug.

Voor een website met pagina's, nieuws en een formulier is het overdreven. Je krijgt er een bouwstap bij, meer code die de bezoeker moet binnenhalen, en een afhankelijkheid van versies die om de zoveel tijd bijgewerkt moeten worden. Wat die raamwerken en bibliotheken doen staat bij webontwikkelingsbibliotheken.

Krijg je een voorstel waarin zo'n raamwerk zit, vraag dan wat het oplost dat zonder niet lukt. Komt daar geen concreet antwoord op, dan is het meestal de voorkeur van de bouwer en niet de behoefte van je bedrijf. Dat is trouwens ook een prima reden, zolang jij weet dat je die keuze betaalt.

Full-stack in de WordPress-wereld

Voor de meeste Nederlandse bedrijfssites is dit de praktijk waar het over gaat. Er wordt geen applicatie vanaf nul gebouwd, er wordt gewerkt binnen een bestaand systeem.

Full-stack betekent dan: een thema of paginabouwer inrichten, een eigen plugin schrijven voor maatwerk, de database schoonhouden, de site snel houden, en een koppeling leggen met het pakket waar de klant zijn administratie in doet.

Dat is minder glamoureus dan een applicatie in React en het is voor een gewoon bedrijf bijna altijd de verstandigere route. Je krijgt onderhoud, updates en beveiliging van een gemeenschap van duizenden mensen erbij, in plaats van van één bouwer.

De vaardigheid die hier het meest telt is weten wanneer je iets niet zelf bouwt. Wie voor elk probleem een eigen oplossing schrijft, levert iets af dat over drie jaar niemand meer durft aan te raken.

Wanneer één iemand voor alles beter is

Bij kleine en middelgrote projecten. Er zit geen overdracht tussen voorkant en achterkant, dus er gaat niets verloren in de vertaling en er hoeft niemand op elkaar te wachten.

Ook bij onderhoud is het prettig. Eén iemand die het hele systeem kent kan een probleem opsporen zonder dat er twee partijen naar elkaar wijzen. Dat scheelt vooral op de momenten dat het haast heeft.

En het is goedkoper, simpelweg omdat er minder overleg nodig is. Bij een project van een paar weken kan overleg zomaar een kwart van de tijd opeten zodra er meerdere partijen bij betrokken zijn.

De grens ligt ergens rond het punt waarop meerdere mensen tegelijk aan hetzelfde systeem moeten werken. Daaronder is één persoon sneller, daarboven wordt hij de flessenhals.

Waar de grens ligt

Dit hoort er eerlijk bij. Iemand die alles doet is op geen enkel onderdeel zo goed als een specialist die er dagelijks mee bezig is.

Bij een ingewikkelde applicatie met veel gebruikers, bij hoge eisen aan beveiliging, of bij een ontwerp dat tot op de pixel moet kloppen, is die specialist het waard. Hetzelfde geldt als er echt zware toegankelijkheidseisen liggen, bijvoorbeeld bij werk voor een overheidsorganisatie.

Er is nog een risico dat minder wordt genoemd: één persoon is één punt van uitval. Wordt hij ziek of stopt hij ermee, dan ligt je project stil. Dat is te ondervangen, maar dan moet je het wel vooraf regelen.

De praktische lijn: voor een website, een webshop of een koppeling tussen systemen is één ervaren persoon meestal beter. Voor een softwareproduct met een team eromheen wordt specialisatie logisch.

Waar je op let bij het inhuren

• Vraag naar werk dat live staat. Niet naar een portfolio met plaatjes, maar naar sites die je kunt bezoeken en testen.
• Kijk of het snel is. Draai een van hun sites door PageSpeed Insights. Dat zegt meer dan een gesprek.
• Vraag wat er gebeurt na de oplevering. Wie doet de updates, wie draait de back-ups, wie is bereikbaar als er iets stukgaat.
• Vraag hoe ze omgaan met beveiliging. Iemand die daar geen concreet antwoord op heeft, heeft er niet over nagedacht. Een goed antwoord gaat over invoer controleren, rechten regelen en bijwerken, zoals bij het beveiligen van een WordPress-website.
• Let op maatwerk waar het niet nodig is. Een zelfgebouwd beheersysteem is leuk voor de bouwer en een risico voor jou.

Vraag ook naar de dingen die misgingen. Iemand die eerlijk kan vertellen welk project uit de hand liep en wat hij daarvan leerde, is doorgaans prettiger om mee te werken dan iemand bij wie alles altijd goed ging.

Op papier vastleggen

Hier gaat het bij kleine bedrijven het vaakst mis, en dat merk je pas op het moment dat de samenwerking stopt.

Het auteursrecht op de code ligt volgens de Auteurswet bij de maker, ook als jij ervoor betaalt. Overdracht kan alleen schriftelijk, met een akte. Zonder die afspraak heb jij gebruiksrecht en blijft hij eigenaar. Bij iemand in dienst ligt het anders, dan liggen de rechten bij de werkgever.

Regel daarnaast een verwerkersovereenkomst als de ontwikkelaar bij persoonsgegevens kan, en dat kan hij vrijwel altijd, want hij heeft toegang tot je database. Dat is geen formaliteit; artikel 28 van de AVG vraagt erom.

Let bij een zzp'er ook op de vorm van de samenwerking. Sinds 1 januari 2025 handhaaft de Belastingdienst weer op schijnzelfstandigheid. Werkt iemand jarenlang fulltime voor jou, op jouw plek en onder jouw aansturing, dan is dat een aandachtspunt voor jou als opdrachtgever en niet alleen voor hem.

Zorgen dat je eruit kunt stappen

Vraag dit bij het eerste gesprek, niet bij het laatste. Wie het dan een rare vraag vindt, geeft daarmee al antwoord.

Zorg dat je domeinnaam, je hosting en je accounts op jouw naam staan en dat jij de eigenaar bent, niet je bouwer. Dit is de meest voorkomende vorm van vastzitten die ik tegenkom, en het is achteraf een hoop gedoe om recht te trekken.

Zorg daarnaast dat de code in een versiebeheersysteem staat waar jij bij kunt, bijvoorbeeld op GitHub, en dat er ergens een pagina ligt met wachtwoorden, afspraken en de eigenaardigheden van het project. Een opvolger die dat kan lezen is in een week ingewerkt.

En vraag om leesbare code met uitleg erbij op de plekken waar het slim is opgelost. Slimme code die niemand begrijpt is minder waard dan saaie code die een ander kan overnemen.

Een zzp'er, een bureau of iemand in dienst

Voor een gewone bedrijfssite werkt een ervaren zelfstandige vaak het beste. Je praat met de persoon die het ook doet, de lijnen zijn kort en je betaalt niet mee aan een organisatie eromheen.

Bij een bureau koop je continuïteit. Er is iemand bereikbaar als er iemand ziek is, er zijn afspraken over reactietijden, en er is een tweede paar ogen. Dat kost meer en het is bij een webshop die geld verdient meestal terecht.

Iemand in dienst nemen wordt pas logisch als er structureel werk is, en dat is bij een bedrijf van vijf man zelden zo. Een halve dag per week aan de site besteden is geen baan.

Wat ik in de praktijk het meest zie werken: een vaste zelfstandige of vast bureau voor het bouwen en onderhouden, en daarnaast iemand binnen het bedrijf die de teksten en de afbeeldingen zelf kan aanpassen. Voor dat laatste hoef je geen programmeur te zijn.

Zelf full-stack worden

De volgorde die werkt: eerst HTML en CSS, dan JavaScript, dan een taal voor de achterkant, dan databases. Sla die volgorde niet over, want elke stap steunt op de vorige.

Kies daarna één stapel en blijf daar een tijd bij. Van taal wisselen voordat je de eerste beheerst is de fout die ik het vaakst zie, en het voelt productief terwijl het dat niet is.

Bouw iets dat je zelf wilt hebben. Cursussen afmaken levert minder op dan één project waar je echt doorheen moet, met alle vastlopers die daarbij horen. Zet het daarna online, want pas dan loop je tegen de dingen aan die in geen enkele cursus staan.

Leer versiebeheer vanaf dag één en leer hoe je met een API praat, want koppelingen met andere systemen zijn in de praktijk een groot deel van het werk.

Reken op een half jaar tot een jaar serieus oefenen voordat je iets kunt opleveren dat mensen mogen gebruiken. Het bouwen leer je snel; omgaan met fouten, beveiliging en andermans code duurt langer.

Het vak verschuift

Gereedschap dat code voorstelt en aanvult heeft het schrijven sneller gemaakt. Dat klopt, en tegelijk verandert er minder dan vaak wordt gezegd.

Wat sneller gaat is het typewerk en de standaardstukken. Wat niet sneller gaat is bepalen wat er precies gebouwd moet worden, uitzoeken waarom iets in een bestaand systeem stukgaat, en verantwoordelijkheid nemen als er gegevens op het spel staan. Daar zit het meeste van de tijd, en daar zit ook de waarde.

Er komt bovendien werk bij. Code die met hulp is geschreven moet nog steeds beoordeeld worden, en iemand die niet weet wat er staat kan dat niet. Wie een voorstel klakkeloos overneemt, bouwt er lekken en trage zoekopdrachten in.

Voor een opdrachtgever verandert er weinig aan de vraag die telt: kan deze persoon uitleggen wat hij bouwt en wat er gebeurt als het misgaat.

Veelgestelde vragen over full-stack ontwikkeling

Wat is het verschil tussen full-stack, front-end en back-end?

Front-end is alles wat in de browser draait en wat de bezoeker ziet. Back-end is alles wat op de server gebeurt: gegevens opslaan, rechten controleren, mails versturen. Full-stack is allebei, door dezelfde persoon.

Wat moet een full-stack developer kennen?

HTML, CSS en JavaScript voor de browserkant, één taal voor de serverkant met de bijbehorende database, en versiebeheer met git.

Daar komt in de praktijk bij: weten hoe een server werkt, hoe je fouten opspoort, hoe je koppelingen met andere systemen maakt en hoe je iets veilig houdt. Dat laatste rijtje is meestal het verschil tussen een beginner en iemand die je kunt inhuren.

Wat is een tech stack?

De vaste combinatie van onderdelen waar een project op draait: besturingssysteem, webserver, programmeertaal, database en de code in de browser.

LAMP staat voor Linux, Apache, MySQL en PHP en is de meest gebruikte, onder meer omdat WordPress erop draait. MEAN en MERN gebruiken van boven tot onder JavaScript.

Heb ik een full-stack developer nodig voor een gewone bedrijfswebsite?

Voor het bouwen meestal niet, want daar komt zelden programmeerwerk aan te pas. Voor het onderhoud en voor maatwerk wel.

De vraag die er echt toe doet is wie er bereikbaar is als je site eruit ligt of je formulier het niet meer doet. Dat is vaker het probleem dan de bouw zelf.

Is WordPress-werk ook full-stack ontwikkeling?

Ja, als er programmeerwerk bij zit. Een eigen plugin schrijven, een koppeling maken met een boekhoudpakket of de database opschonen zijn allemaal werk aan beide kanten van de stapel.

Een site in elkaar zetten met een paginabouwer zonder een regel code is dat niet, en dat is geen diskwalificatie. Het is gewoon ander werk.

Kan één persoon een webshop bouwen en onderhouden?

Ja, en dat gebeurt ook volop. Bij een webshop met een standaardpakket en een paar koppelingen is één ervaren persoon meestal sneller en goedkoper dan een team.

Regel dan wel wat er gebeurt als die persoon er even niet is. Bij een winkel die dagelijks omzet draait wil je een tweede partij die erbij kan, ook al doet die normaal niets.

Wat bepaalt wat een full-stack developer kost?

Ervaring, de stapel waar hij in werkt en of hij ook verantwoordelijkheid neemt voor het beheer erna. Dat laatste is het verschil dat de meeste mensen niet meerekenen.

Vraag altijd apart naar het onderhoud per maand en naar wat er gebeurt bij spoedgevallen. Een lage bouwprijs met een open einde erna wordt bijna altijd duurder dan een reële prijs met vaste afspraken.

Van wie is de code die iemand voor mij bouwt?

Van de maker, tenzij je schriftelijk iets anders afspreekt. De Auteurswet legt het auteursrecht bij degene die het maakt, en overdracht kan alleen met een akte.

Leg daarom bij de opdracht vast dat de rechten naar jou overgaan, of spreek een gebruiksrecht af dat ruim genoeg is om ermee te kunnen verhuizen. Voor iemand in dienst geldt dit niet: dan liggen de rechten bij de werkgever.

Hoe lang duurt het om full-stack developer te worden?

Een half jaar tot een jaar stevig oefenen om iets te kunnen bouwen dat mensen mogen gebruiken, en een paar jaar voordat je zelfstandig verantwoordelijk kunt zijn voor een systeem waar geld doorheen gaat.

Wat die tijd bepaalt is niet hoeveel talen je kent, maar hoe vaak je iets hebt zien stukgaan en hebt gerepareerd.

Is full-stack ontwikkelaar een goed beroep?

Voor wie het leuk vindt om van een probleem tot een werkende oplossing te komen: ja. Er is werk, je kunt zelfstandig aan de slag en je kunt vanaf een klein project doorgroeien.

Het nadeel is dat je op meerdere terreinen moet bijblijven en dat je op geen ervan de diepste bent. Wie liever ergens de beste in wordt, is beter af met specialiseren.

Welke stapel kan ik het beste leren?

Wil je met websites voor bedrijven werken, dan is PHP met MySQL de meest praktische keuze, omdat daar in Nederland verreweg de meeste vraag zit. Wil je richting applicaties, dan is JavaScript met Node.js de logische route.

Kies er één en blijf daar minstens een jaar bij. Wat je in de eerste stapel leert over structuur en fouten opsporen neem je daarna gewoon mee.

Vervangt AI het werk van een full-stack developer?

Nee, maar het verschuift wel waar de tijd heen gaat. Het schrijven van standaardcode gaat sneller; bepalen wat er moet komen, een fout in een bestaand systeem vinden en verantwoordelijkheid dragen niet.

Wat het wel doet is de lat verleggen. Wie alleen code kon overtikken heeft het moeilijker gekregen. Wie snapt hoe het geheel in elkaar zit, is juist meer waard geworden.