Lumello — salonsoftware zonder commissies

Het probleem

De salonsoftware-markt in Nederland heeft een tarieven-cultuur die je in geen enkele andere SaaS-vertical tegenkomt. Treatwell rekent 35% commissie op nieuwe klanten. Fresha rekent 20% commissie en daarboven €14,95 per teamlid. Salonized rekent €72,50 per maand voor vijf medewerkers. Voor een eenmanszaak die net begonnen is, betekent dat tussen de 15% en 40% van de marge naar het platform — voor wat in essentie een agenda, kassa en online-booking is.

De markt heeft zich daar zo aan aangepast dat veel salons gewoon aannemen dat dit de prijs van digitalisering is. Twee kappers waar ik vroeger geknipt werd, hebben in vier jaar nooit op een berekening gestaan die hen liet zien hoeveel ze structureel kwijt waren. Het was gewoon "wat het kost".

Lumello's vraag was: kan een platform met dezelfde feature-set draaien voor één vast bedrag — geen commissie, geen per-medewerker, geen verborgen kosten — en alsnog gezond zijn?

Aanpak

Het antwoord op die vraag is een prijsmodel met drie eigenschappen:

1. Eén vast bedrag. €9,95 per maand (Launch Deal). Geen tieren op basis van team-omvang, geen tarieven op basis van transactie-volume.
2. Geen commissie. Op niets. Niet op nieuwe klanten via online boeken, niet op kassa-transacties, niet op terugkerende afspraken.
3. Onbeperkt medewerkers. Een salon met twee kappers betaalt hetzelfde als een salon met twaalf. Schalen vergroot je marge in plaats van je software-rekening.

Dat is een product-keuze, niet een marketing-trucje. Om het te kunnen, moest het product zelfvoorzienend zijn op onboarding (zonder support-tickets per salon), op betaling (Mollie SEPA Direct Debit, geen credit-card-flow), en op upgrades (in-app, zonder sales-gesprek).

Tech-stack

Next.js 15 met App Router, server actions voor mutaties (de hele agenda en kassa zijn server-action-driven, geen REST-API), Supabase voor data + auth, Mollie voor recurring SEPA-incasso van het abonnement, Resend voor transactionele mail (booking-bevestigingen, herinneringen, factuur-PDF's). next-intl voor de Nederlandse + Engelse versie. TypeScript strict, geen any, geen @ts-ignore.

De agenda is custom-gebouwd op CSS Grid in plaats van een library als FullCalendar. Reden: salonafspraken zijn níet generieke kalender-events. Ze hebben buffer-tijd, dubbele bezetting voor kleurservices, "snel-tussendoor"-vinkjes voor walk-ins. Een generieke kalender-component leidt tot drie maanden adapter-code; een eigen grid leidt tot twee weken bouwen plus volledige controle over de UX.

War story

In week zes van bouw, twee weken voor de first-user-launch, kwam het probleem dat geen designer voorziet: een kapper boekte twee klanten parallel in voor dezelfde slot, op verschillende stoelen, met hetzelfde medewerker-lid. Volgens onze domein-logica was dat een dubbele boeking. Volgens zijn domein-logica was dat een kleurbehandeling waar hij na de aanvang 30 minuten kon overschakelen naar een knipbeurt op stoel twee.

De fix was niet "voeg een dubbele-bezetting-knop toe". De fix was: stop met aannemen dat een afspraak één persoon claimt. Een afspraak claimt tijd-intervallen op een medewerker met een staat (actief / passief / wachtend). De data-model-wijziging duurde een dag; de UI om het zichtbaar te maken duurde een week. Maar zonder die wijziging zou Lumello structureel verkeerd hebben aangenomen hoe Nederlandse salons werken.

Lesje: de eerste echte gebruiker breekt je domein-model. Niet je interface — je model. Bouw zo dat dat haalbaar is in dag-één.

Resultaat

Lumello is live op lumello.nl voor €9,95 per maand. Online booken is GDPR-compliant geïmplementeerd. De vergelijkings-pagina op /vergelijken laat eerlijk zien wat een salon bespaart per maand tegenover Salonized, Treatwell en Fresha — getallen die teruggrijpen op publieke tarieven van die platforms, niet op marketing-claims.

Geen verzonnen "+38% boekingen" hier. De salons die overstappen, blijven dat doen omdat het rekensommetje rond komt — niet omdat ik beloof dat hun omzet stijgt.

Wat ik leerde

Tegen een markt met verborgen kosten ingaan is geen UX-probleem. Het is een transparency-probleem. De vergelijkings-pagina is daarom geen marketing-asset maar een product-feature: salons kunnen daadwerkelijk hun huidige factuur invoeren en zien wat ze besparen. Dat soort eerlijke vergelijking maakt het waardevoorstel niet zachter, het maakt het scherper.

Server actions vervangen 80% van wat ik vroeger in een API-laag zou bouwen. Geen REST-routes, geen client-side fetch-orchestratie, geen mismatched zod-schemas tussen frontend en backend. Eén type-signature van knop tot database. Voor een MVP met één bouwer is dat de juiste keuze.

CTA

Bouw je iets in een markt met scheef-getrokken prijsmodellen — SaaS waar de gevestigde spelers met commissies werken? Stuur me een bericht. Eerlijke prijs als product-feature is technisch interessanter dan het lijkt.