← brussel hub

brussel / web development

webontwikkeling in brussel.

tweetalige sites en applicaties die niet vastlopen op een templatekeuze.

een brussels bedrijf bouwt niet voor nederland alleen en niet voor wallonie alleen. de site moet als native lezen in nl en fr, soms in en voor de eu-tail, met een cms-architectuur die het in-house team aanpast zonder dev-cycle. we bouwen die laag op next.js, webflow of framer, afhankelijk van waar het zwaartepunt ligt.

start een project

01 . waarom brussel

de context die deze bouw vraagt.

stack: next.js / webflow / framertalen: nl, fr, en standaardcms: in handen van het content-teamperformance: lighthouse 95+

brussel is de enige belgische markt waar de helft van jullie kopers verwacht dat de site native frans is, en de andere helft native nederlands. een vertaling van een nederlandse master-versie wordt onmiddellijk gehoord. de gevolg-discipline daarvan zit in de url-structuur (eigen prefixen per locale, niet querystring), de hreflang-set, de schema-markup per taal, en de sitemap-architectuur. de meeste belgische sites krijgen dit verkeerd, hetzij door een wordpress-multilingual-plugin die de canonical-tags slecht uitlevert, hetzij door een framework-keuze die nl als default neemt en de andere talen als afterthought toevoegt.

we bouwen drie stack-typen, afhankelijk van waar het zwaartepunt van jullie site zit. next.js voor applicatie-zware projecten waar de site eigenlijk een productlaag is (calculators, dashboards, betaalflows, member-portalen). webflow voor catalog-zware, cms-zware merken waar het content-team de redactie wil doen zonder dev-tussenkomst. framer voor merken waar interactie en motion de differentiator zijn en de cms-laag lichter is. de keuze valt in week 1 van het project, gemotiveerd, niet als reflex.

de seo-architectuur zit erin vanaf dag 1. heading-hierarchie, schema-markup voor article, product, faq en breadcrumbs, og en twitter-cards, robots.txt en sitemap.xml per locale, hreflang correct (geen kruislingse canonical, het belgische sitenfoutje nummer 1). lighthouse 95+ op mobile is acceptance-criterium, niet een nice-to-have. de meeste brusselse agencies leveren 60-70 op mobile, en wijzen dan naar de afbeeldings-grootte. dat is niet de bouw die wij doen.

de gdpr-laag is in brussel zwaarder geladen dan in vlaanderen of wallonie, omdat een groot deel van de kopers een eu-instelling of eu-instelling-leverancier is. een gdpr-banner die niet voldoet aan de gegevensbeschermingsautoriteit (gba) richtlijnen 2026 is een directe afkeur. we bouwen die laag eu-compliant uit (cookie-categorieën, opt-in voor analytics, doel-specifieke toestemming voor third-party), met een gdpr-tweetalige toelichting op pad-niveau, niet enkel in een footer-link.

02 . wat we bouwen

concrete deliverables voor een brusselse bouw.

03 . bewijs

de case die dit draagt.

04 . methode

de fases in volgorde.

fase 0

discover.

week 1-2

kickoff workshop, stack-keuze (next.js vs webflow vs framer) onderbouwd, content-architectuur op tafel, drie locale-conventies vastgelegd, gdpr-baseline gemeten, eerste lighthouse-baseline van bestaande site.

fase 1

design.

week 3-5

homepage, twee hoofdtemplates, mobile en desktop. content-team review na week 4. design-systeem als figma-styleguide opgeleverd voor sign-off. drietalige microcopy op tafel.

fase 2

build.

week 6-9

stack-build met cms-architectuur live, drietalige routing, schema-markup, content-migratie, gdpr-laag geconfigureerd. acceptance-testen op lighthouse, wcag en cross-browser per locale.

fase 3

launch.

week 10

dns-migratie, ga4 verbonden, search console submit, handover-documentatie overhandigd, twee content-trainingssessies in nl en fr. 90-dagen platform-care begint.

05 . vragen

wat brusselse kopers eerst vragen.

01

ik heb al een framerwebsite. is een rebuild nodig?

niet altijd. een audit op de bestaande framer-build duurt drie werkdagen en geeft een eerlijk antwoord: rebuild als de design-systeem-laag fundamenteel niet meer past, retainer als alle gewenste aanpassingen binnen het bestaande systeem passen. de meeste brusselse kantoren hebben een retainer-shape nodig, geen rebuild iedere 18 maanden. dat is een agency-economisch artefact, geen klantbehoefte.

02

ondersteunen jullie wordpress?

ja, voor projecten waar wordpress de juiste keuze is (typisch: een redactionele site met meerjarige content-bibliotheek die in wordpress is gegroeid en niet zonder verlies te migreren is). voor een nieuI build is wordpress zelden de eerste keuze in 2026, gezien de plugin-sprawl en de upgrade-loterij. wij zeggen dat ook eerlijk in de scoping-week.

03

hoe zit het met meertaligheid? nl, fr en en?

url-prefixen per locale (/nl, /fr, /en), hreflang correct, sitemap per taal, og-tags vertaald, schema-markup per taal. drietaligheid is geen plugin, het is een architectuur-keuze die in fase 0 wordt vastgelegd. waalse en brussel-fr kopers zien een native franse surface, niet een vertaling van een nederlandse master.

04

wat met de gegevensbeschermingsautoriteit en gdpr-banners?

de gba heeft in 2024 zijn cookie-banner richtlijnen aangescherpt. we bouwen die laag eu-compliant uit (cookie-categorieën, opt-in voor analytics, doel-specifieke toestemming voor third-party scripts), met een tweetalige toelichting op pad-niveau. dpa-mapping op alle externe scripts. dit is geen post-launch checklist, het is een dag-1 build-criterium.

05

kan ons content-team zelf werken na launch?

ja. dat is het hele punt van de structured content model in fase 0. we leveren een 20-pagina operationele handleiding in nl en fr plus twee trainingssessies bij launch. cms-aanpassingen op vraag zitten in de platform retainer voor de eerste 90 dagen kostloos.

06

wij werken met een eu-instelling als hoofdklant. hoe relevant is dat?

zeer relevant. eu-instellingen hebben verhoogde verwachtingen op accessibility (wcag 2.1 aa minimum, soms aaa), op gdpr-discipline, op publication-pipeline-discipline. ik heb jobfin.be gebouwd voor de fod financien onder government-grade security review en wcag 2.1 aa. die discipline ligt nu in elke brusselse bouw die wij doen, niet als premium-tier maar als standaard.

07

wanneer is webflow beter dan next.js?

webflow wint als jullie redactie-team zelfstandig wil werken op een catalog-zwaar, cms-zwaar oppervlak (case studies, methodology-articles, sector-content). next.js wint als de site eigenlijk een productlaag is (calculator, dashboard, betaalflow, member-portaal). de keuze valt in week 1, met een lijst use-cases tegen elke stack-shape gehouden. geen reflex, geen agency-default.

06 . verder

aangrenzende oppervlakken.

klaar om te bouwen?

start een project.

schets jullie project in vier zinnen: huidige stack, talen, schaal van de site, en wat de huidige bouw niet meer aankan. wij antwoorden binnen een werkdag met een concreet vervolg.