Verder dan Vercel en Netlify: op zoek naar slimmere alternatieven voor frontend hosting

Nog niet zo lang geleden was het deployen van een website een rommelige aangelegenheid. Je huurde een VPS, installeerde Nginx, configureerde SSL-certificaten, maakte je druk om poorten en permissies, en hoopte dat de server niet platging tijdens het uitrollen van een nieuwe versie. Toen kwamen Netlify en Vercel. Opeens kon je je GitHub-repo koppelen, je code pushen en stond je website live. Voor frontend developers was dat pure magie.

Het idee was simpel maar krachtig: de infrastructuur abstraheren zodat developers zich op de code kunnen focussen. Vercel en Netlify hosten niet alleen statische bestanden; ze boden continuous deployment, automatische previews, wereldwijde CDN's en zelfs serverless functions. Ze werden het standaardantwoord op de vraag: "waar moet ik mijn frontend hosten?"

Maar zoals bij veel revoluties, bracht de volgende fase compromissen met zich mee. Wat deze platformen zo handig maakte, maakte ze ook rigide. En naarmate teams en projecten groeiden, begonnen sommige van die nadelen pijn te doen.

Wat Vercel en Netlify hebben opgelost

Beide platformen losten een groot pijnpunt op in frontend workflows. Voorheen was deployment een bijzaak, vaak afgehandeld door die ene backend engineer die de server begreep. Opeens kon elke frontend developer met een gerust hart deployen. Bij elke git push werd je code binnen enkele seconden gebouwd, gedeployed en wereldwijd geserveerd. Je hoefde niet na te denken over CDN's, SSL of caching.

Ze maakten ook samenwerking makkelijker. Preview-URL's voor pull requests veranderden de manier waarop teams code beoordeelden. Serverless functions maakten het mogelijk om backend-logica te draaien zonder een aparte API te beheren. En omdat ze gebouwd waren rondom Git-workflows, hoefden developers geen nieuwe tools te leren.

Voor kleine teams, zijprojecten of startups was het perfect. Snel, strak en modern.

De eerste barstjes

De problemen ontstaan wanneer je gaat schalen. Niet noodzakelijkerwijs in verkeer, maar in de complexiteit van je team of stack.

Het eerste probleem is vendor lock-in. Deze platformen vertrouwen op eigen configuraties en deployment-systemen. Zodra je Vercel's edge functions of Netlify's forms gebruikt, deploy je niet alleen code: je deployt hún variant ervan. Later overstappen kan betekenen dat je functies moet herschrijven of je hele CI/CD opnieuw moet configureren.

Het tweede probleem is de beperkte ondersteuning voor verschillende stacks. Ze blinken uit in Next.js, Gatsby of statische SvelteKit-sites, maar als je project een backend, aangepaste API of database-integratie heeft, valt de eenvoud weg. Veel teams eindigen uiteindelijk toch met het elders deployen van delen van hun app.

Dan is er de prijsstelling. Het begint goedkoop, maar zodra je team groeit, betaal je per seat, per build-minuut en per aanroep van een functie. Dat model straft samenwerking af.
Vooral agencies lopen hier snel tegenaan: opeens kost elke developer extra, zelfs als ze maar aan één project voor een klant werken.

En misschien wel de grootste frustratie is het gebrek aan controle. Je kunt niet zelf bepalen hoe je CDN zich gedraagt, in welke regio functies draaien of hoe schaalregels worden toegepast. De eenvoud die het geweldig maakte voor individuen, maakt het beperkend voor teams die flexibiliteit nodig hebben.

Waarom wij naar alternatieven zochten

Bij We Do Dev Work werken we in een agency-omgeving. Meerdere developers, meerdere projecten, verschillende frameworks, verschillende klanten. We hebben een opzet nodig die met ons mee kan groeien en zich aanpast aan hoe wij werken, niet andersom.

We willen niet per seat betalen. We willen niet dat ons verteld wordt welke stack we moeten gebruiken. En we hebben een systeem nodig dat consistent is over projecten heen: zodat wanneer de ene developer een project afrondt, een ander het kan overnemen zonder een steile leercurve.

Daarom zijn we verder gaan kijken dan Vercel en Netlify. We wilden iets dat naadloos integreert met ons ecosysteem: TypeScript, .NET, PostgreSQL, SvelteKit en Supabase. Iets dat ons controle geeft over infrastructuur, kosten en toegang.

Dat bracht ons bij AWS Amplify.

Waarom we van AWS Amplify houden

Amplify is niet zo flitsend als Vercel. Het profileert zich niet met hippe animaties of magische woorden als "instant deploy". Maar onder de motorkap biedt het de juiste balans tussen gemak en controle.

Het ondersteunt moderne frameworks zoals React, Vue en SvelteKit zonder er één op te dringen. Je koppelt je repo en het bouwt bij elke push. Net als de anderen. Maar omdat het onderdeel is van AWS, integreert het natuurlijk met de rest van het ecosysteem. Database nodig? Je kunt RDS opstarten of Supabase koppelen. Afbeeldingen hosten? Gebruik S3. Edge caching nodig? CloudFront staat voor je klaar.

We vinden het prettig dat alles transparant is. Je ziet waar je voor betaalt, regio per regio. Je wordt niet gefactureerd voor teamleden. Je hebt geen verborgen kosten voor functies of limieten op build-minuten. Als een project groeit, schalen we het op dezelfde manier als onze backend.

Nog een groot pluspunt: consistentie. Elk project dat we deployen volgt dezelfde Amplify-opzet. Dit betekent dat onze developers tussen klantprojecten kunnen schakelen zonder nieuwe pipelines of eigen workflows te hoeven leren. Het houdt ook alle omgevingen onder onze controle. Geen afhankelijkheid van een leverancier die morgen zijn prijzen of functies kan wijzigen.

Alternatieven die het ontdekken waard zijn

Amplify werkt goed voor ons, maar het is niet de enige weg. Afhankelijk van de grootte en focus van je project zijn er andere goede opties:

• Cloudflare Pages is uitstekend voor statische en JAMStack-sites. Snelle wereldwijde levering, ingebouwde edge functions en eenvoudige Git-integratie. Het is ook een van de meest betaalbare opties voor simpele frontends.

• Render biedt een interessante balans tussen eenvoud en full-stack flexibiliteit. Het ondersteunt web services, cron jobs, PostgreSQL en background workers. Allemaal met een relatief eenvoudig dashboard.

• Fly.io richt zich op performance en nabijheid. Je kunt ge-dockeriseerde apps dicht bij je gebruikers draaien, ideaal voor projecten waar latency cruciaal is.

• DigitalOcean App Platform voelt als een vriendelijkere versie van AWS. Het ondersteunt de meeste frameworks, biedt managed databases en is zeer geschikt voor kleine bedrijven. Toch is DigitalOcean om de een of andere reden niet voor iedereen de favoriete keuze.

• Google Cloud Run biedt serieuze schaalbaarheid, hoewel het technischer is. Het kan alles hosten wat in een container zit, maar vereist meer configuratie en DevOps-kennis.

Elk van deze tools heeft zijn eigen voor- en nadelen. De kunst is om de tool te matchen met het team.

Wanneer serverless niet het antwoord is

Serverless hosting klinkt als de toekomst — en dat is het vaak ook — maar niet voor alles. We hebben projecten gezien waarbij serverless uiteindelijk duurder en complexer uitpakte dan een klassieke VPS-opzet.

De problemen komen meestal neer op schaal en consistentie. Voor langdurige taken of zwaar verkeer kunnen de kosten van serverless de pan uit rijzen. Cold starts kunnen de gebruikerservaring schaden, en debuggen over meerdere lambda-aanroepen kan moeizaam zijn. En omdat elke functie geïsoleerd draait, zijn caching en state management lastiger.

Een klassieke opzet op basis van containers kan goedkoper zijn, makkelijker te debuggen en nog steeds schaalbaar. Met de juiste DevOps-inrichting: CI/CD-pipelines, autoscaling en load balancing, krijg je voorspelbare kosten en prestaties. Het is misschien niet "modern" in de zin van een buzzword, maar het is nog steeds hoe veel grootschalige applicaties succesvol draaien.

Met andere woorden: de juiste architectuur is de architectuur die bij het probleem past, niet bij de trend.

Onze aanpak bij We Do Dev Work

Voor ons wint flexibiliteit. We gebruiken Amplify wanneer we snelle frontend-deployments nodig hebben, geïntegreerd met Supabase voor data en authenticatie. Wanneer we meer controle nodig hebben, kiezen we voor klassieke container-deployments op AWS ECS of zelfs managed VPS-omgevingen.

Ons doel is altijd hetzelfde: snelle, betrouwbare en onderhoudsvriendelijke hosting met transparante kosten. Het gaat er niet om dat we de nieuwste tool achterna jagen. Het gaat erom de juiste tool voor de klus te kiezen.

En het volledige proces van code tot productie in eigen hand houden.

We bewonderen nog steeds wat Vercel en Netlify naar het ecosysteem hebben gebracht. Ze hebben moderne frontend-ontwikkeling toegankelijk en plezierig gemaakt. Maar gemak heeft zijn grenzen. Voor een agency die met meerdere stacks, teams en klanten werkt, is het beheren van de eigen pipeline belangrijker dan one-click deploys.

Tot slot

Frontend deployment heeft een lange weg afgelegd: van handmatige FTP-uploads naar serverless CDN's met previews en functions. Maar het verhaal is nog niet af. We gaan een fase in waarin teams zowel gemak als controle willen. Waar kosten voorspelbaar moeten zijn, omgevingen reproduceerbaar en tools open.

Voor ons bij We Do Dev Work biedt AWS Amplify die balans. Het is betrouwbaar, flexibel en past natuurlijk binnen onze stack. Maar de echte les is dit: laat hosting je architectuur niet bepalen.

Kies een platform dat jouw workflow dient, niet andersom.
Dat is hoe je schaalbare systemen bouwt — en een duurzame agency.