Webshop Laten Maken: Kosten en Proces voor het MKB (2026)

Vraag drie bureaus een offerte voor een webshop, en de bedragen kunnen een factor tien uiteenlopen: de een noemt drieduizend euro, de ander twaalfduizend, een derde veertigduizend. Alle drie kunnen eerlijk zijn. Een webshop is geen product met één prijs — het is een productcatalogus, een afrekenproces, een betaalintegratie, een ontwerp, en meestal een koppeling met het systeem dat al uw facturatie of voorraad regelt, en elk van die onderdelen kan onafhankelijk van de andere klein of groot zijn.

Deze gids laat zien wat de kosten van een webshop voor een Nederlands MKB-bedrijf in 2026 daadwerkelijk bepaalt, hoe een bouwtraject eruitziet zodra u er een laat maken, waar een compliant afrekenproces op moet letten, en wat u voorbereidt voordat u een ontwikkelaar belt.

Platform, open source, of volledig maatwerk

De meeste MKB-webshops vallen in een van drie categorieën, en die keuze bepaalt de kosten meer dan bijna al het andere.

Een hostingplatform (het Shopify-model: abonnementssoftware met hosting en updates inbegrepen) staat het snelst live en vraagt het minst technisch beheer, tegen een doorlopend abonnement en minder ruimte om iets te doen waar het platform niet voor gebouwd is.

Een open-source webshop (het WooCommerce-model: een plugin bovenop een contentsysteem dat u zelf host) ruilt een lagere doorlopende prijs in voor meer inrichtings- en onderhoudswerk — iemand moet de onderliggende software gepatcht houden, en hosting is uw eigen verantwoordelijkheid.

Volledig maatwerk is pas zinvol als uw catalogus, prijslogica of afrekenproces écht niet in een van beide modellen past — configureerbare producten met prijsregels die geen plugin ondersteunt, bijvoorbeeld, of een webshop die een live productdatabase moet delen met een bestaand magazijnsysteem. Voor een standaardcatalogus met standaard betaal- en verzendbehoeften is maatwerk meestal de dure manier om hetzelfde resultaat te bereiken dat een platform al biedt.

Wat de prijs daadwerkelijk bepaalt

Binnen elk van de drie routes bewegen dezelfde variabelen de prijs op of neer:

• Omvang en structuur van de catalogus. Vijftig eenvoudige producten kosten veel minder om in te richten dan tweeduizend producten met varianten (maat, kleur, materiaal), omdat elke variant de data vermenigvuldigt die gemodelleerd, geïmporteerd en synchroon gehouden moet worden.
• Ontwerp. Een ingericht sjabloon kost een fractie van een volledig maatwerkontwerp rond uw merk.
• Koppelingen. Een betaalprovider is vrijwel een gegeven. Verzenddiensten, een bestaand boekhoudpakket, een magazijn- of voorraadsysteem en een CRM voegen elk koppelwerk toe, en de kosten daarvan hangen volledig af van of het andere systeem een gedocumenteerde, ondersteunde koppeling biedt of pas met maatwerk met uw webshop kan praten.
• Meertaligheid en meerdere valuta, als u buiten de Nederlandse markt verkoopt.
• Verwachte bezoekersaantallen en prestatie-eisen — een shop die een piek bij een flitsactie verwacht, heeft andere infrastructuur nodig dan een catalogus met weinig verkeer.

Byteet's eigen prijsniveaus voor 2026

Dit zijn onze eigen inschattingen voor een Nederlands MKB-project in 2026, gebaseerd op de scope-categorieën hierboven, niet een prijs overgenomen van een specifiek platform of bureau — zie het als een planningsrange, geen vaste prijs, want uw eigen catalogus en koppelingen bewegen u binnen een niveau omhoog of omlaag.

Reken bovenop de bouwprijs apart op hosting, transactiekosten en doorlopend onderhoud — doorgaans een paar honderd euro per maand voor een starter- of MKB-shop, meer zodra catalogus, verkeer of koppelingen groeien. Een offerte die alleen de lancering dekt en niets zegt over wat daarna komt, is geen complete offerte.

Hoe een bouwtraject er in de praktijk uitziet

• Intake. Uw productcatalogus, doelgroep en benodigde koppelingen worden in kaart gebracht voordat er ontwerpwerk begint — dit is waar de scope wordt vastgelegd, en overslaan hiervan is de meest voorkomende reden dat een "vaste prijs" later toch oploopt.
• Ontwerp. Categorie- en productpagina's, het winkelmandje en het afrekenproces worden beoordeeld als klikbare mockups voordat de bouw begint, want een afrekenproces dat na livegang wordt herontworpen kost veel meer dan een dat op een mockup wordt opgevangen.
• Bouw en koppelingen. De webshop zelf, de betaalprovider, verzending en eventuele koppelingen met uw backoffice worden gebouwd en aangesloten, meestal in fasen zodat werkende onderdelen onderweg beoordeeld kunnen worden in plaats van pas aan het einde.
• Testen. Bestellingen, mislukte betalingen, voorraad die tijdens het afrekenen opraakt, en randgevallen zoals gedeeltelijke terugbetalingen worden getest met echte scenario's, niet alleen het ideale pad.
• Livegang en overdracht. U krijgt toegang tot elk betrokken account en systeem — hosting, betaalprovider, het platform zelf — plus documentatie, zodat wisselen van ontwikkelaar later nooit betekent dat u helemaal opnieuw begint.

Wat u voorbereidt voordat u een ontwikkelaar belt

• Uw productdata, ook in een ruwe spreadsheet — namen, prijzen, varianten, afbeeldingen. Wie zonder dit een offerte maakt, gokt naar de catalogusomvang uit de variabelen hierboven.
• Een keuze voor een betaalprovider, of op zijn minst de shortlist — dit beïnvloedt zowel de kosten als welke platforms realistisch zijn.
• Uw verzend- en afhandelingsproces zoals het vandaag daadwerkelijk verloopt, want "hoe bestellingen echt het pand verlaten" blijkt vaak complexer dan ondernemers het uit hun hoofd beschrijven.
• Elk bestaand systeem waarmee de shop moet praten — boekhoudsoftware, een voorraadsysteem, een CRM — en of dat systeem een gedocumenteerde manier heeft waarop andere software ermee kan koppelen.

Het afrekenproces en de AVG

Een webshop-afrekenproces verzamelt per definitie persoonsgegevens — naam, adres, e-mail, betaalgegevens — waardoor het direct onder de Algemene verordening gegevensbescherming (AVG) valt. Twee punten uit de regels zoals die nu daadwerkelijk staan, verdienen het om vanaf dag één in het afrekenproces te zitten, niet er later bij geplakt te worden.

Ten eerste is de juridische grondslag voor het verzamelen van die gegevens tijdens het afrekenen normaal gesproken duidelijk: de AVG erkent verwerking die noodzakelijk is "om een overeenkomst uit te voeren" als een van de zes wettelijke grondslagen, en een bestelling afronden is precies dat geval. De grens die daarbij hoort is even direct: alleen gegevens die daadwerkelijk nodig zijn om de bestelling uit te voeren en te leveren, vallen onder die grondslag. Een veld dat naar de geboortedatum van een klant vraagt, toegevoegd omdat het later handig kan zijn voor marketing, heeft een eigen grondslag nodig (doorgaans toestemming), niet de bestelling zelf.

Ten tweede: richt het afrekenproces niet standaard in met een verplicht account. In december 2025 publiceerde de Autoriteit Persoonsgegevens aanbevelingen van de European Data Protection Board die stellen dat een verplicht account voor een eenmalige aankoop in de meeste gevallen niet nodig is en op gespannen voet kan staan met het AVG-principe om niet meer gegevens te verzamelen dan een doel vereist — de aanbeveling is om een gastoptie als privacyvriendelijke standaard aan te bieden, en een verplicht account te reserveren voor gevallen zoals een abonnementsdienst of een afgesloten ledenomgeving. Die aanbevelingen stonden op het moment van publicatie nog open voor consultatie, met een deadline van 12 februari 2026 — behandel het dus als de richting waarin toezichthouders bewegen, niet als een vaststaande regel. Hoe dan ook kost het inrichten van een gastoptie als standaard niets extra bij een nieuwe bouw, en vermindert het doorgaans ook het aantal afgebroken bestellingen.

Los van het afrekenproces zelf gelden hier ook de algemene AVG-verplichtingen die al gelden voor elk bedrijf dat klantgegevens verwerkt: verzamel niet meer dan nodig, beperk wie binnen uw bedrijf de gegevens kan zien, bewaar ze niet langer dan het doel vereist, en heb een plan klaar voor het melden van een datalek als die zich voordoet. Niets hiervan is specifiek voor webshops — het is de basis waaronder elk Nederlands bedrijf dat persoonsgegevens verwerkt al opereert.

Wat u vastlegt in het contract

• Eigendom van de shop en de data. Leg schriftelijk vast dat u eigenaar wordt van de productcatalogus, het ontwerp en de klantgegevens zodra het project is betaald — niet een gebruiksrecht op een platform dat iemand anders beheert.
• Wie de accounts beheert. Hosting, het betaalprovideraccount, het domein en de platforminlog horen op naam van uw bedrijf te staan, niet op het persoonlijke account van de ontwikkelaar, zodat u nooit buitengesloten raakt van uw eigen shop.
• Een onderhoudsafspraak, niet alleen een overdracht. Bepaal vóór livegang wie een beveiligingsupdate installeert, wie een bug oplost die in week drie opduikt, en hoe een reactietijd eruitziet.
• Een verwerkersovereenkomst, als de ontwikkelaar of hun hostingpartij na livegang namens u persoonsgegevens van klanten verwerkt — wat het normale geval is bij een gehoste webshop. Dit valt onder dezelfde AVG die uw afrekenproces regelt, en hoort in het contract te staan voordat de bouw begint, niet erna.

FAQ

Wat kost een webshop laten maken? Voor een Nederlands MKB-bedrijf in 2026 kost een eenvoudige sjabloonshop doorgaans EUR 2.500 tot 6.000, een shop met maatwerkontwerp en enkele koppelingen EUR 7.000 tot 15.000, en een grote of sterk gekoppelde shop vanaf EUR 15.000. Hosting, transactiekosten en onderhoud zijn aparte, doorlopende kosten.

Wat is het verschil tussen een webshop laten maken en zelf bouwen? Een doe-het-zelf-platform kost minder vooraf en staat sneller live, maar u richt het zelf in en onderhoudt het zelf. Een ontwikkelaar laten bouwen of inrichten kost meer, maar levert een ontwerp en koppelingen op die aansluiten bij uw daadwerkelijke catalogus, plus iemand die verantwoordelijk is als er iets misgaat.

Moet ik klanten verplicht een account laten aanmaken? De huidige aanbevelingen van privacytoezichthouders wijzen de andere kant op: voor een eenmalige aankoop is een verplicht account doorgaans niet nodig, en een gastoptie als standaard wordt aangeraden.

Hoe lang duurt het om een webshop te laten bouwen? Een starter shop op een sjabloonplatform kan in een paar weken live staan. Een MKB-shop met maatwerkontwerp en een paar koppelingen duurt doorgaans zes tot tien weken. Een grote of sterk gekoppelde shop kan drie maanden of langer duren, afhankelijk van het aantal externe systemen waarmee hij moet koppelen.

Heb ik een verwerkersovereenkomst nodig voor een webshop? Verwerkt uw ontwikkelaar of hun hostingpartij namens u persoonsgegevens van klanten — het geval bij vrijwel elke gehoste webshop — dan is het antwoord ja, en die overeenkomst hoort te staan voordat de shop de eerste bestelling ontvangt.

Praat met ons over de scope, niet alleen de prijs

Een offerte is pas te vergelijken zodra de scope erachter duidelijk is — omvang van de catalogus, welke koppelingen, en wie na livegang eigenaar is van wat. Ons team Web & Software Development scopet webshopprojecten op basis van uw daadwerkelijke catalogus en systemen, en vertelt u eerlijk wanneer een sjabloonplatform het betere antwoord is. Zodra klant- en betaalgegevens door het afrekenproces gaan stromen, kan ons team Cybersecurity & Identity de verwerkersovereenkomst en toegangsopzet beoordelen voordat u iets tekent. Weegt u ook af tussen maatwerk en een platform, dan behandelt onze gids over maatwerk software laten ontwikkelen die bredere afweging.