Where it started
I joined Msool in March 2025 as Senior Product Designer. By May 2026 I was writing the requirements and making the product calls, and the title changed to Product Owner.
Msool is a bilingual Arabic/English property management platform for short-term rental hosts in Saudi Arabia and the wider Gulf — calendars, bookings, guest messages, channels, teams.
Client feedback kept circling the same thing — commission — so we studied the market — how hosts actually get their bookings, and what the alternatives were charging them. It lined up: hosts were paying commission on bookings they had already won. That became the freemium bet.
This case follows that initiative, which I own end to end — from the first market study through launch and the work that followed.
Scope
- Product strategy
- Prioritisation
- Business rules
- Requirements & specs
- Product design
- UAT & release
- Post-launch feedback
The bet
Give every host a free booking website. Earn only when a booking happens.
Free to start. 4% per booking.
Guests were already messaging hosts directly. Hosts were sending them to an OTA to finish the booking, paying commission on a relationship they built themselves.
A free branded booking site for every host, plus the dashboard to run it — calendar, reservations, properties, payouts. 4% per booking. Paid plans for hosts who outgrow free.
Who it's for
Individual host
1–3 units. Already taking direct bookings.
Professional host
4–20 units. Upgrades for channels.
Property manager
20+ units. Full platform.
Every host starts free. The difference is what they need next.
My Approach
Every feature ran the same loop. Referral rewards, a guest portal rebuild and an AI layer were all shaped and all deferred — none of them created a booking, and bookings were the only thing V1 was measured on.
- 01
Analyse
Client feedback synthesis and a competitor teardown. Free was opened to every host regardless of size — the segments differ in where they go next, not in where they start.
- 02
Document
The rules before the screens. Invoicing, commission at 4%, VAT on top, and what happens to the money when a guest cancels. Written once in Notion, argued once, then settled — the single reference for design, engineering and QA.
- 03
Design
A 9-step onboarding wizard that ends with a live booking site and a shareable landing page. Bilingual, RTL first, live preview at every step, and a recovery email at each drop-off point so a host who leaves halfway comes back to where they stopped.
- 04
Hand off
Jira stories written numbers-first: a worked example with real figures, then the rules, then acceptance criteria. Epics stay open until testing signs them off — I close them, not the team.
- 05
Test
Usability testing on the onboarding wizard, then UAT against the spec. Bugs triaged by real impact, not by who reported them.
- 06
Launch
Ship, collect post-launch feedback, and feed it into the next cycle. The loop doesn't end at release.
The Solution
Five decisions that turned the bet into a product.
From signup to a live site
Nine steps, and the host ends with a working booking page on their own subdomain. Language, identity, style, contact, then their first property. A live preview updates as they go, so they always know what they're building.
Live before they've paid anything.
A page for the bio, not the browser
Hosts don't send links to websites. They send links from social profiles. So onboarding also produces a landing page: identity, tagline, contacts, and their properties as cards. It's the first thing a host shares and the first thing a guest sees.
Their audience becomes the channel.
A money model with one source of truth
Commission at 4%, VAT added on top, and every invoice issued under Msool's name. The host wallet shows what came in, what Msool took, and what's owed — with the same numbers the backend calculated. No client-side maths anywhere.
Every figure comes from one formula.
Verification that gates bookings, not signups
Permits are a regulatory requirement. Verification stays optional during setup, so nothing blocks a host from finishing. But a property can't publish or take a booking until its permit clears — checked live against the regulator's API, with four states surfaced across the dashboard.
Optional to start. Required to earn.
Plans, shaped
Freemium only works if there's somewhere to go next. I shaped the upgrade path — what stays free, what unlocks, and how a host discovers the limit without hitting a wall.
Shaped, not shipped.
What testing changed
I tested every flow against the acceptance criteria and tiered what came back — payment and booking data first, cosmetic last. Three guest emails got cut because they only repeated what the screen already said.
One thing I got wrong: when a payment link expired, the booking was being cancelled outright and the dates released. A host could lose a real reservation because a guest was slow to pay. An expired link is a payment problem, not a booking decision — so the booking now moves to expired, and the dates stay held until the host decides.
Get those rules right and the screens almost design themselves.
The Outcome
- websites created
- 47
- direct bookings
- 128
- properties published
- 83
Success was defined before anything shipped: bookings created, not signups. Websites created was the leading indicator we watched for drop-off, but a website that never takes a booking earns nothing — so it was never the goal.
Msool now earns when hosts earn. Every rule above was written once and holds across invoicing, cancellation, wallet, and upgrade.