Een week onder de motorkap
Sommige weken voegen we features toe. Deze week niet. Deze week hebben we drie dingen rustiger, sneller en robuuster gemaakt — het soort werk waar niemand iets van merkt, behalve dat alles zich net iets beter gedraagt.
17 april 2026Niels van Haren4 min lezen
Achter elk SaaS-product dat “gewoon werkt” zit een laag die niemand ziet. Bij Merkflow proberen we die laag serieus te nemen — niet als after-thought, maar als onderdeel van het product zelf. Deze week stonden drie dingen op het bord: de manier waarop we engagement binnenhalen van social platforms, de manier waarop we nieuwe dingen testen voordat ze live gaan, en de manier waarop we met betalingen omgaan. Alle drie kleinere investeringen die samen een groot verschil maken in hoe zeker we kunnen bouwen.
01 Van polling naar realtime
Tot deze week vroegen we Meta regelmatig: “zijn er nieuwe comments of DM’s?” Dat werkt prima, maar het is fundamenteel het verkeerde model — je stelt steeds dezelfde vraag, meestal voor niets, en als het antwoord ja is loop je al achter op de werkelijkheid. Bij schaal wordt dat bovendien duur: honderden API calls per dag waarvan de meeste niks opleveren.
Deze week zijn we overgestapt op Meta webhooks. Nu duwt Meta zelf events onze kant op zodra er iets gebeurt — een comment, een mention, een DM. Onze backend (Kotlin + Spring WebFlux, reactief van nature) pakt ze op, verifieert de HMAC-signatuur zodat we zeker weten dat het echt van Meta komt, en schrijft ze via R2DBC naar PostgreSQL. Geen polling loop meer. Geen achterstand.
Stack
Kotlin Spring WebFlux HMAC-SHA256 R2DBC PostgreSQL
Voor de gebruiker verandert één ding: reacties op je posts komen nu nagenoeg realtime binnen in de engagement inbox, in plaats van in batches. Voor ons verandert vooral de kwaliteit van het signaal — push is inherent eerlijker dan pull.
02 Een nep-social-platform in eigen huis
Het tweede ding is misschien nog interessanter. Tot voor kort was ons test-setup redelijk klassiek: ofwel je test tegen echte social media accounts (risico op echte posts op echte profielen, rommelige OAuth, onbetrouwbare rate limits), ofwel je test tegen gemockte unit tests (snel, maar ze vertellen je niks over hoe het product écht aanvoelt).
Daarom hebben we een volledig gemockte social-platform omgeving gebouwd. Niet een paar stub-responses — een echte dashboard waarin we posts zien verschijnen, comments kunnen achterlaten, OAuth flows kunnen doorlopen, webhook events kunnen triggeren. Hetzelfde Merkflow-product, maar in plaats van naar Meta en LinkedIn te praten, praat het naar onze eigen mock backend — die de echte API response shapes nabootst tot in detail.
End-to-end testen zonder ooit een echte API aan te raken — dat verandert hoe snel je durft te bouwen.
De truc zit ‘m in één env var. De WebClients in de backend hebben configureerbare base URL’s — in mock modus wijzen ze naar onze interne mock server, in live modus naar de echte platforms. Zelfde codepaden, andere bestemming. Dat betekent dat we nieuwe features end-to-end kunnen valideren, inclusief OAuth callbacks en webhook deliveries, zonder risico voor de productieaccounts van onze gebruikers.
Stack
Spring Boot 4 React 19 + ViteSpring Profiles Traefik
03 Mollie, met een veiligheidsnet
En tot slot: betalingen via Mollie staan live. We hebben bewust gekozen voor Mollie — Amsterdams, PSD2-compliant, SEPA en iDEAL first — in plaats van de voor de hand liggende Amerikaanse opties. Dat scheelt ons GDPR-hoofdpijn rondom data-overdrachten buiten de EU, en het geeft onze gebruikers vertrouwde betaalmethodes.
De integratie zelf is een bekend patroon: checkout sessie aanmaken, klant redirecten naar Mollie, webhook terug naar ons met de bevestiging. Wat we er extra bij hebben gebouwd is een schone scheiding tussen test en live sleutels, met een veiligheidsnet dat voorkomt dat we per ongeluk een test-sleutel in productie zetten of andersom. Simpel op papier, maar het soort guardrail dat je dankbaar bent als het een keer iets onderschept.
04 Waarom dit soort werk ertoe doet
Geen van deze drie dingen zijn features die je op een landingspagina zet. Ze zitten niet in de productdemo. Ze maken geen screenshot beter.
Maar ze bepalen wél hoe snel we de volgende features kunnen bouwen, hoe zeker we kunnen zijn dat ze werken als ze live gaan, en hoe kalm onze gebruikers kunnen bouwen bovenop wat er al staat. Dat is wat we bedoelen als we zeggen dat Merkflow een platform is voor operators die rust zoeken in hun social media — die rust moet eerst in het fundament zitten voordat het aan de oppervlakte kan ontstaan.
Volgende week: wat feature-werk. Maar deze week sluiten we tevreden af.
