The first salons are signing up for Salonnare - what I learned from launch to first customers

A few weeks ago I launched Salonnare: a multi-tenant SaaS for beauty salons - online booking, point of sale with iDEAL, inventory, client CRM, loyalty, automated reminders. Since then the first real sign-ups have started coming in, and that's the moment a product goes from "finished" to "now it really begins". This is an honest account of what actually happens after you hit deploy.

What's under the hood

Salonnare runs on the stack I use by default: Next.js for the marketing site, a React SPA for the app, a Node.js + TypeScript API with Drizzle ORM, MariaDB as the database, all containerized in Docker on a single VPS. Every salon gets its own subdomain (yoursalon.salonnare.com) and fully isolated data via a tenant-scoped query wrapper. Integrations: Stripe Connect and Mollie Connect for payments, Google Reserve, Resend for email, WhatsApp Business for reminders, Cloudflare for DNS and custom domains. 100+ idempotent database migrations, five languages, and a separate encrypted "vault" for special-category personal data (allergies, medication) because the GDPR requires it.

That's the version I'd put in a proposal. The reality of the first few weeks is messier - and more instructive.

What the first sign-ups taught me

1. "Live" doesn't mean "done". It means "now the real questions start". My local tests, integration tests and Playwright suite caught hundreds of bugs. The first real user found one within a day that no test had caught: an edge case in the demo-data seed that briefly left a freshly created salon in a "stranded" state. Tests cover the paths you think of. Real users walk the paths you didn't. That's not a failure of your tests - it's the reason you keep your first cohort small.

2. Onboarding friction is the real funnel. I'd been fixated on features. But the first question from a salon isn't "can I set up a loyalty program" - it's "how do I get my existing clients and schedule into this". Importing, opening hours, treatments, prices, staff: that's the part where people drop off if it takes too many clicks. I've since added an onboarding checklist to the dashboard and filled the demo tenant with realistic data so a new salon immediately sees what it should look like instead of staring at a blank screen.

3. Per-tenant infrastructure is more work than you think. A subdomain per salon sounds simple. But then you also want per-tenant email deliverability (a dedicated sending domain with DKIM/SPF, otherwise reminders land in spam), optionally a custom domain with its own SSL certificate, per-tenant rate limiting, and cross-tenant leakage ruled out in every query. I've since automated the sending-domain part: for every new tenant, a verified <slug>.mail.salonnare.com is provisioned automatically via the Resend and Cloudflare APIs. You don't see that kind of plumbing as a user - but without it the product simply works badly.

4. Compliance isn't a side issue, it's a feature. For a Dutch SaaS that processes salon client data - including health data - the GDPR isn't a checkbox you tick afterwards. I built an encrypted vault for special-category data, a GDPR export flow, a DPA dossier, sub-processor documentation, and cookie consent with Consent Mode v2. Customers actually ask about this. "Do you have a data processing agreement" is a normal first question, not a formality. It has to be there before the first salon signs up.

5. Your first customers are your best roadmap. No amount of solo brainstorming replaces one real salon saying "I'm missing X" or "Y is confusing". The priority list I had before launch looks different now - not because I was wrong, but because reality is sharper than an assumption.

Why I'm putting this on a dev blog

This isn't Salonnare marketing. The point is this: at VanIersel Development I don't build demos that look good in a portfolio. I build production software with real users, payments, compliance obligations and the messy reality of maintaining it afterwards. Salonnare is the proof of that - a multi-tenant SaaS I not only built but also run, with the monitoring, backups, security hardening and hot-fixes that come with it.

If you're having a web application or SaaS built, you want someone who knows the difference between "it works on my machine" and "it's been running in production for months without the customer noticing". That experience comes from nowhere else but doing it yourself.

What's next

The first salons are in. The coming months are about smoothing out onboarding, fixing the bugs that real users find, and recalibrating the roadmap on what customers actually ask for - not on what I thought they'd ask for. Building in public also means admitting this: the real work begins after launch.

Have an idea for a web application or SaaS yourself, or an existing product that's due for a serious technical upgrade? Book a free intro call - within three business days you'll know what it costs and how we'll approach it.