De eerste salons melden zich aan voor Salonnare - wat ik leerde van launch tot eerste klanten
Salonnare staat live en de eerste aanmeldingen komen binnen. Een eerlijk verslag van wat er gebeurt nadat je op 'deploy' drukt: de bugs die je tests niet vonden, onboarding-frictie, per-tenant infrastructuur en waarom 'live' niet 'klaar' betekent.
Een paar weken geleden zette ik Salonnare live: een multi-tenant SaaS voor beauty salons - online afsprakensysteem, kassa met iDEAL, voorraad, klanten-CRM, loyaliteit, automatische herinneringen. Sindsdien komen de eerste echte aanmeldingen binnen, en dat is het moment waarop een product van "af" naar "begint pas net" gaat. Dit is een eerlijk verslag van wat er daadwerkelijk gebeurt nadat je op deploy drukt.
Wat er onder de motorkap zit
Salonnare draait op de stack die ik standaard gebruik: Next.js voor de marketing-site, een React SPA voor de app, een Node.js + TypeScript API met Drizzle ORM, MariaDB als database, en alles geconteineriseerd in Docker op één VPS. Elke salon krijgt een eigen subdomein (jouwsalon.salonnare.com) en volledig geïsoleerde data via een tenant-scoped query-wrapper. Integraties: Stripe Connect en Mollie Connect voor betalingen, Google Reserve, Resend voor mail, WhatsApp Business voor herinneringen, Cloudflare voor DNS en custom domains. 100+ idempotente database-migraties, vijf talen, en een aparte versleutelde "vault" voor bijzondere persoonsgegevens (allergieën, medicatie) omdat de AVG dat eist.
Dat is de versie die ik in een offerte zou zetten. De realiteit van de eerste weken is rommeliger - en leerzamer.
Wat de eerste aanmeldingen me leerden
1. "Live" betekent niet "klaar". Het betekent "nu beginnen de echte vragen". Mijn lokale tests, integratietests en Playwright-suite vonden honderden bugs. De eerste echte gebruiker vond er binnen een dag eentje die geen enkele test had gevonden: een edge-case in de demo-data-seed waardoor een net aangemaakte salon kort in een "stranded" staat zat. Tests dekken de paden die je bedenkt. Echte gebruikers lopen de paden die je niet bedacht. Dat is geen falen van je tests - het is de reden dat je een eerste cohort klein houdt.
2. Onboarding-frictie is de echte funnel. Ik had me blindgestaard op features. Maar de eerste vraag van een salon is niet "kan ik een loyaliteitsprogramma instellen" - het is "hoe krijg ik mijn bestaande klanten en agenda hierin". Importeren, openingstijden, behandelingen, prijzen, personeel: dat is het stuk waar mensen afhaken als het te veel klikken kost. Ik heb sindsdien een onboarding-checklist op het dashboard gezet en de demo-tenant gevuld met realistische data zodat een nieuwe salon meteen ziet hoe het eruit hoort te zien in plaats van naar een leeg scherm te staren.
3. Per-tenant infrastructuur is meer werk dan je denkt. Een subdomein per salon klinkt simpel. Maar dan wil je ook per-tenant e-mail-deliverability (eigen verzenddomein met DKIM/SPF, anders landen reminders in spam), eventueel een custom domein met eigen SSL-certificaat, per-tenant rate-limiting, en cross-tenant lekkage uitsluiten in elke query. Ik heb het verzenddomein-deel inmiddels geautomatiseerd: bij elke nieuwe tenant wordt via de Resend- en Cloudflare-API's automatisch een geverifieerd <slug>.mail.salonnare.com aangemaakt. Dat soort plumbing zie je niet als gebruiker - maar zonder dat werkt het product gewoon slecht.
4. Compliance is geen bijzaak, het is een feature. Voor een Nederlandse SaaS die klantgegevens van salons verwerkt - inclusief gezondheidsgegevens - is de AVG geen checkbox achteraf. Ik heb een versleutelde vault gebouwd voor bijzondere persoonsgegevens, een GDPR-export-flow, een DPA-dossier, sub-processor-documentatie, en cookie-consent met Consent Mode v2. Klanten vragen hier daadwerkelijk naar. "Hebben jullie een verwerkersovereenkomst" is een normale eerste vraag, geen formaliteit. Dat moet er gewoon zijn voordat de eerste salon zich aanmeldt.
5. De eerste klanten zijn je beste roadmap. Geen enkele hoeveelheid eigen brainstormen vervangt één echte salon die zegt "ik mis X" of "Y is verwarrend". De prioriteitenlijst die ik vóór launch had, ziet er nu anders uit - niet omdat ik het mis had, maar omdat de werkelijkheid scherper is dan een aanname.
Waarom ik dit op een dev-blog zet
Dit is geen Salonnare-marketing. Het punt is dit: bij VanIersel Development bouw ik geen demo's die er goed uitzien in een portfolio. Ik bouw productie-software met echte gebruikers, betalingen, compliance-verplichtingen en de rommelige realiteit van onderhoud daarna. Salonnare is daar het bewijs van - een multi-tenant SaaS die ik niet alleen heb gebouwd maar ook run, met de monitoring, backups, security-hardening en hot-fixes die daarbij horen.
Als je een webapplicatie of SaaS laat bouwen, wil je iemand die het verschil kent tussen "het werkt op mijn machine" en "het draait al maanden in productie zonder dat de klant het merkt". Die ervaring komt nergens anders vandaan dan uit het zelf doen.
Wat nu
De eerste salons zijn binnen. De komende maanden gaan over onboarding gladstrijken, de bugs oppakken die echte gebruikers vinden, en de roadmap herijken op wat klanten daadwerkelijk vragen - niet op wat ik dacht dat ze zouden vragen. Building in public betekent ook dit toegeven: het echte werk begint na de launch.
Heb je zelf een idee voor een webapplicatie of SaaS, of een bestaand product dat toe is aan een serieuze technische upgrade? Plan een gratis kennismaking - binnen drie werkdagen weet je wat het kost en hoe we het aanpakken.
