Lumello — salon software without commissions

The problem

The Dutch salon software market has a pricing culture you won't find in any other SaaS vertical. Treatwell takes 35% commission on new clients. Fresha takes 20% commission plus €14.95 per team member. Salonized charges €72.50 per month for five team members. For a one-person salon just getting started, that means somewhere between 15% and 40% of margin flows to the platform — for what is essentially a calendar, a point-of-sale and online booking.

The market has adjusted to this so thoroughly that many salons just assume this is the price of going digital. Two hairdressers I used to get my haircuts from never ran the math in four years of operation. It was simply "what it costs."

Lumello's question: can a platform with the same feature set run for a single flat price — no commission, no per-seat fees, no hidden costs — and still be healthy?

Approach

The answer is a pricing model with three properties:

1. One flat price. €9.95 per month (Launch Deal). No team-size tiers, no transaction-volume tiers.
2. No commission. On anything. Not on new clients booking online, not on POS transactions, not on returning appointments.
3. Unlimited team members. A salon with two stylists pays the same as a salon with twelve. Scaling grows your margin instead of your software bill.

That's a product decision, not a marketing trick. To make it work, the product had to be self-sufficient on onboarding (no per-salon support tickets), on payment (Mollie SEPA Direct Debit, no credit-card flow) and on upgrades (in-app, no sales call).

Tech stack

Next.js 15 with App Router, server actions for mutations (the entire calendar and POS are server-action-driven, no REST API), Supabase for data + auth, Mollie for recurring SEPA debit of the subscription, Resend for transactional mail (booking confirmations, reminders, invoice PDFs). next-intl for the Dutch + English version. TypeScript strict, no any, no @ts-ignore.

The calendar is custom-built on CSS Grid rather than a library like FullCalendar. Reason: salon appointments are not generic calendar events. They have buffer time, double-booking for color services, "quick-walk-in" toggles for unscheduled clients. A generic calendar component leads to three months of adapter code; a hand-rolled grid leads to two weeks of building plus full control over UX.

War story

In week six of the build, two weeks before first-user launch, a problem appeared that no designer anticipates: a hairdresser booked two clients into the same slot, on different chairs, with the same staff member. According to our domain logic that was a double booking. According to his domain logic that was a color treatment where, 30 minutes in, he could switch to a haircut on chair two.

The fix wasn't "add a double-booking toggle." The fix was: stop assuming an appointment claims one person. An appointment claims time intervals on a staff member with a state (active / passive / waiting). The data-model change took a day; the UI to expose it took a week. But without that change, Lumello would have structurally mismodeled how Dutch salons actually operate.

Lesson: the first real user breaks your domain model. Not your interface — your model. Build so that's achievable on day one.

Result

Lumello is live at lumello.nl for €9.95 per month. Online booking ships GDPR-compliant. The comparison page at /compare shows honestly what a salon saves per month against Salonized, Treatwell and Fresha — numbers that reference those platforms' published tariffs, not marketing claims.

No fabricated "+38% bookings" here. The salons that switch keep switching because the math works out — not because I promise their revenue will grow.

What I learned

Going up against a market with hidden costs isn't a UX problem. It's a transparency problem. That's why the comparison page isn't a marketing asset but a product feature: salons can actually enter their current invoice and see what they save. That kind of honest comparison doesn't soften the value proposition, it sharpens it.

Server actions replace 80% of what I would have built as an API layer. No REST routes, no client-side fetch orchestration, no mismatched zod schemas between frontend and backend. One type signature from button to database. For an MVP with one builder, that's the right call.

CTA

Building something in a market with skewed pricing — SaaS where the incumbents work on commission? Send me a note. Honest pricing as a product feature is more technically interesting than it sounds.