E-commerce ontwikkeling op maat
E-commerce ontwikkeling op maat is er voor retailers van wie het platform niet meer past: het thema kan de catalogus niet kwijt, de checkout kan geen tweede valuta aan, en elke nieuwe markt betekent weer een plugin die net niet werkt. Globaprom bouwt de ontbrekende stukken (gelokaliseerde webshops, meertalige catalogi en koppelingen voor betaling, btw en ERP) met ontwikkeling op basis van kunstmatige intelligentie (AI), opgeleverd in weken tegen vaste prijzen. We komen voort uit twintig jaar vertaalwerk, dus grensoverschrijdende eisen zijn ons startpunt, geen extraatje. Wat we bouwen, hoe we meertalige en internationale complexiteit aanpakken, en wat het kost tegenover platformlicenties en forfaits van bureaus: het staat hieronder, als onderdeel van onze diensten voor softwareontwikkeling op maat.
Wanneer Shopify, WooCommerce en Magento niet meer passen
Elk e-commerceplatform heeft een plafond voor maatwerk. Shopify, WooCommerce en Magento (nu Adobe Commerce) dekken het standaardpad prima: één storefront, één taal, één belastingregime, een catalogus die in het sjabloon past. Groei breekt dat pad.
De symptomen zijn steeds dezelfde in de webshops die we doorlichten:
- Complexiteit in de catalogus. Configureerbare producten, B2B-prijslijsten of regionale assortimenten die het datamodel van het platform niet kan weergeven.
- Gaten in de checkout. Een betaalmethode, belastingregel of verzendbeperking die je doelmarkt verwacht en je platform niet ondersteunt.
- Wildgroei aan plug-ins. Vijftien extensies die gaten dichten, elk met een eigen abonnement, eigen conflicten en eigen upgraderisico.
- Handmatige lijm. Personeel dat orders overtikt in het ERP (enterprise resource planning) of vertalingen met de hand in het CMS zet.
- Taalmuren. Een storefront die alleen in het Engels overtuigend verkoopt, terwijl je bezoekcijfers iets anders zeggen.
Geen van deze symptomen vraagt om een ander platform. Ze vragen om software op maat eromheen: het e-commerceplatform uitbreiden via zijn API's (application programming interfaces) in plaats van vechten met de sjablonen. Dat werk staat hieronder beschreven.
Wat we bouwen: webshops, headless, PIM, OMS en retourportalen
We bouwen de maatwerklaag rond je commerce-stack. Typische projecten:
- Webshops op maat. Ecommerce website ontwikkeling op maat (in het Engels) wanneer de themawinkel je conversie afknijpt: productconfigurators, B2B-bestelflows, regionale varianten van de webshop.
- Headless commerce projecten. Headless commerce scheidt de webshop die de klant ziet van de commerce-back-end, verbonden via API's. Onze gids over headless commerce ontwikkeling (in het Engels) legt uit wanneer dat loont, en wanneer het overdreven is.
- Platform-apps. Shopify app-ontwikkeling op maat (in het Engels) voor functionele gaten: bundels, B2B-prijzen, specifieke verzendlogica.
- PIM en catalogustools. PIM-systemen (product information management, productinformatiebeheer) centraliseren productdata (beschrijvingen, kenmerken, afbeeldingen, vertalingen) en voeden elk kanaal vanuit één bron. We bouwen PIM-software voor het mkb (in het Engels) (kmo in Vlaanderen) en middelgrote catalogi, vertaalworkflow inbegrepen.
- OMS-dashboards. Een OMS (order management system, orderbeheersysteem) bundelt de orders van elke webshop en marketplace op één scherm. Bekijk onze projecten voor een order management systeem op maat (in het Engels).
- Retourportalen. Selfservice-retouren met gelokaliseerde labels, koppeling met de vervoerder en terugbetalingsregels per markt. Elk project heeft een vaste scope en een vaste prijs. Je keurt scope, prijs en opleverdatum goed voordat we code schrijven, en de opgeleverde code is van jou. Het volledige verloop van een opdracht staat beschreven in hoe we scopen, bouwen en controleren.
Een storefront lokaliseren gaat, goed gedaan, over meer dan vertaalde tekst:
- Lokale vertrouwenssignalen. De betaalmethoden die men in die markt verwacht, bezorgbeloftes met lokale vervoerders, en juridische pagina's die bij het land passen.
Omdat we twee decennia lang een vertaalbedrijf hebben gerund, bouwen we dit de eerste keer goed. Onze uitleg over grensoverschrijdende e-commerce loopt de volledige stack voor markttoetreding door, en een meertalige webshop bouwen behandelt de storefrontlaag in detail. De onderliggende discipline is meertalige software voor grensoverschrijdende handel: i18n-first architectuur, en geen vertaalde tekst die achteraf op een Engelstalige bouw wordt geplakt.
Meertalige productdata: PIM, vertaalpijplijnen voor de catalogus en hreflang die klopt
Meertalige e-commerce is eerst een datavraagstuk en pas daarna een vertaalvraagstuk. Een catalogus van 5.000 producten in vier talen is 20.000 productrecords om aan te maken, bij te werken en synchroon te houden. Webshops die dat in spreadsheets beheren, lopen binnen een kwartaal achter: prijzen wijzigen, beschrijvingen worden aangepast, en vertalingen raken ongemerkt achterhaald.
We lossen het op met drie onderdelen:
- Een PIM als enige bron van productwaarheid. Elk attribuut, elke beschrijving en elke afbeelding staat in één systeem, met per taal zicht op wat af is. Kanalen (storefronts, marktplaatsen, feeds) zijn exports, geen aparte kopieën.
- Een vertaalpijplijn in plaats van kopiëren en plakken. Nieuwe en gewijzigde content gaat automatisch naar vertalers (machinaal, menselijk of gemengd, jij kiest per contenttype) en komt terug in het PIM met versiebeheer. We bouwden zulke pijplijnen eerst voor onze eigen vertaalpraktijk, daarna voor klanten.
- Hreflang die klopt. Hreflang is de HTML-annotatie die zoekmachines vertelt welke taal- en regioversie van een pagina ze aan welke gebruiker moeten tonen. Gegenereerd uit catalogusdata is het betrouwbaar. Met de hand bijgehouden over duizenden product-URL's gaat het mis, en serveert Google de verkeerde taal aan de verkeerde markt. Wij genereren het programmatisch en toetsen het in CI.
Het resultaat: je voegt een product één keer toe, en het verschijnt correct beschreven, geprijsd en geïndexeerd in elke markt waar je verkoopt.
Betalingen, belastingen en valuta internationaal: Stripe, Adyen, btw-OSS, prijzen in meerdere valuta
Betalingen en belastingen zijn de plek waar grensoverschrijdende webshops geruisloos de meeste omzet verliezen. Het langlopende checkout-onderzoek van het Baymard Institute legt de gemiddelde winkelwagenverlating rond 70%, en betaalfrictie (ontbrekende lokale methoden, onverwachte kosten, gedwongen valutaomrekening) staat steevast tussen de belangrijkste oorzaken. We bouwen de laag voor betalingen en belastingen als maatwerk-integratiewerk:
- Betaalgateways. Een betaalgateway is de dienst die kaart- en walletbetalingen autoriseert en verwerkt. We integreren Stripe, Adyen en PayPal (inclusief methoden per markt: iDEAL in Nederland, Bancontact, de dominante methode, in België, en SEPA-incasso voor terugkerende betalingen) en sturen elke markt naar de methoden die zijn kopers verwachten.
- Prijzen in meerdere valuta. Prijslijsten per markt met gecontroleerde afronding, geen naïeve omrekening tegen de wisselkoers. Je Britse klant ziet een prijs in pond, afgerond als een Britse prijs, niet het resultaat van een omrekening op het moment van afrekenen.
- Btw en OSS. De btw (belasting over de toegevoegde waarde) op je grensoverschrijdende verkopen aan consumenten in andere lidstaten geef je aan via het éénloketsysteem OSS (One Stop Shop): één kwartaalaangifte die alle bestemmingslanden dekt. Twee regels die webshops vaak missen. Je binnenlandse verkopen vallen niet onder de OSS, die blijven in je gewone nationale btw-aangifte. En onder een drempel van € 10.000 aan grensoverschrijdende B2C-verkoop per jaar over de hele EU pas je het tarief van je eigen land toe; daarboven het tarief van het land van je klant. B2B-verkoop tussen btw-plichtige ondernemers loopt doorgaans via btw-verlegging en valt buiten de OSS. We bouwen de tariefslogica, het vastleggen van bewijsstukken en de exports die je boekhouder nodig heeft, en integreren gespecialiseerde belastingmodules (tax engines) wanneer de catalogus dat vereist.
- Beheersing van de PCI DSS-scope. PCI DSS (Payment Card Industry Data Security Standard) is de beveiligingsstandaard van de kaartindustrie. We ontwerpen de checkout zo dat kaartgegevens nooit je servers raken: gehoste velden en gateway-tokens houden je nalevingsscope minimaal. Betaal- en klantgegevens roepen ook vragen op rond de AVG (GDPR). Hoe we beide in een AI-ondersteunde workflow aanpakken, staat beschreven in AI-ondersteunde ontwikkeling en naleving (AVG, PCI DSS).
Integraties: ERP, 3PL en fulfilment, marktplaatsen, carrier-API's
Een storefront die niet praat met de backoffice, maakt werk waar niemand op zit te wachten: orders overtikken, voorraad afstemmen in spreadsheets, per mail antwoorden op "waar blijft mijn bestelling?". Wij bouwen de middleware die dat werk weghaalt.
- ERP en boekhouding. Orders, facturen, voorraadstanden en klantgegevens in beide richtingen synchroon tussen de webshop en systemen als SAP Business One, NetSuite, Odoo of Exact. Onze uitleg over de koppeling tussen webshop en ERP behandelt de patronen, en de foutafhandeling die een orderpiek op Black Friday overleeft.
- 3PL en fulfilment. Een 3PL (third-party logistics provider) slaat je orders op en verzendt ze. Wij koppelen hun API's voor het doorzetten van orders, voorraadsynchronisatie en trackingupdates terug naar de klant.
- Marktplaatskoppelingen. Listings, voorraad en orders synchroon met Amazon, Zalando en andere marktplaatsen, zodat je de catalogus één keer beheert en overal verkoopt.
- Carrier-API's. Tarieven vergelijken, labels aanmaken en tracking bij de vervoerders die elke markt verwacht.
Elke integratie wordt opgeleverd met logging, herhaalpogingen, monitoring en waarschuwingen. Een integratie die stilletjes faalt in je piekweek is erger dan geen integratie.
Kosten en doorlooptijd: e-commerce op maat of een platformlicentie plus bureaucontract
De eerlijke vergelijking is niet "maatwerk tegenover een gratis platform". Het is maatwerk tegenover een platformlicentie plus apps plus een maandelijks bureaucontract: de stapel waar de meeste groeiende webshops echt voor betalen.
Een commercestack in het middensegment combineert doorgaans een platformabonnement, 10 tot 20 betaalde extensies en een maandbedrag aan een bureau voor wijzigingen. Dat terugkerende totaal overstijgt vaak de eenmalige kosten van het bouwen van precies de functionaliteit die het bedrijf nodig heeft, en nog steeds past de webshop niet.
AI-ondersteunde ontwikkeling verandert de bouwkant van die som. Engineers sturen AI-codetools aan die de software genereren, en lezen, testen en verstevigen daarna elke regel. Typische doorlooptijden bij Globaprom:
- App of checkout-uitbreiding voor het platform: 2–3 weken.
- ERP- of 3PL-koppeling: 3–4 weken.
- PIM op maat met vertaalworkflow: 4–6 weken.
- Gelokaliseerde storefront (headless of op het platform): 5–8 weken.
Elk getal loopt van goedgekeurde scope tot productie, tegen een vaste prijs die vaststaat voordat het werk begint. Geen uurtarief, geen open einde. Vraag een offerte met vaste prijs aan en je krijgt een concreet bedrag en een datum terug.
Veelgestelde vragen over e-commerce op maat
Wat kost e-commerce op maat?
De meeste e-commerceprojecten van Globaprom liggen tussen de kosten van één jaar platform- en app-abonnementen en de discoveryfase van een klassiek bureau. De exacte prijs hangt af van functionaliteit, integraties en talen, en staat vast voordat het werk begint. Een afgebakende koppeling begint lager dan een volledig gelokaliseerde storefront; allebei worden ze geoffreerd als één bedrag met een leverdatum.
Hoelang duurt een e-commerceproject op maat?
Weken, geen kwartalen. Een platform-app of één koppeling gaat meestal in 2–4 weken live, een PIM op maat in 4–6 weken, een volledig gelokaliseerde storefront in 5–8 weken. AI-ondersteunde ontwikkeling drukt de bouwfase in elkaar, terwijl engineers van vlees en bloed alles nakijken, testen en verstevigen voor de release.
Moeten we weg bij Shopify of WooCommerce om maatwerk te doen?
Nee. Het grootste deel van ons e-commercewerk breidt een bestaand platform uit via zijn API's: apps op maat, koppelingen, PIM- en OMS-lagen, gelokaliseerde storefronts. Overstappen naar een ander platform is een laatste redmiddel, geen beginpunt. We raden het alleen aan wanneer het datamodel van het platform je catalogus of je markten echt niet kan weergeven.
Hoe maak je een webshop meertalig?
We brengen de productdata samen in een PIM, koppelen een vertaalpijplijn zodat nieuwe content automatisch naar vertalers gaat en terugkomt, lokaliseren storefront en checkout per markt, en genereren de hreflang-annotaties programmatisch. Die architectuur houdt elke taal actueel terwijl de catalogus verandert: geen kopieer-en-plakwerk, geen verouderde vertalingen.
Kunnen jullie internationale betalingen en btw-compliance aan?
Ja. We koppelen betaalproviders als Stripe, Adyen en PayPal aan de lokale betaalmethoden die elke markt verwacht, van iDEAL in Nederland tot Bancontact in België. We bouwen prijzen in meerdere valuta's per markt en implementeren de EU-btw-logica met exports voor de One Stop Shop (OSS). Checkouts worden zo opgezet dat kaartgegevens binnen de betaalprovider blijven, wat de PCI DSS-scope klein houdt.
Wat is headless commerce, en hebben wij dat nodig?
Bij headless commerce staat de frontend van je storefront los van de commerce-backend, verbonden via API's. Je krijgt volledige controle over ontwerp en snelheid, tegen de prijs van meer bewegende delen. Het loont voor webshops met meerdere markten, meerdere kanalen of veel maatwerk. Een webshop in één markt met een passend thema heeft het zelden nodig.
Verkoop in elke markt waar je klanten wonen
Beschrijf het gat in je commerce-stack: de markt die je niet op kunt, de koppeling die je blijft oplappen, de catalogus die je met de hand vertaalt. Wij antwoorden met een vaste scope, een vaste prijs en een leverdatum in weken.