Case Study · Wellness & Healthtech
A GCC wellness marketplace, live on both stores in eight weeks
A Dubai wellness startup needed one app for two audiences — practitioners publishing credentials and availability, clients booking, paying and taking the session. No technical team, a fixed runway, and a scope far larger than the first release could carry.
Dubai, UAE
Wellness & healthtech
Custom app
iPhone & Android, one shared codebase
Client stage
Pre-launch founding team
No technical co-founder and no engineering team — the product team was ours from the first sprint.
Engagement
Ongoing since November 2025
A rebuild and launch, then fortnightly fixed-scope sprints that are still running today.
8 weeks
Kickoff to live on both stores
From kickoff to the app live on the App Store and Google Play, with the core loop working end to end.
30+
features in 8 months
Shipped on a fortnightly cycle, every sprint scoped and agreed before it started.
30+
practitioners on the platform
Onboarded and verified, each with their own credentials, availability and payouts.
The client
A Dubai-based wellness startup building a marketplace for the GCC. On one side, practitioners — hypnotherapists, yoga teachers, psychologists, breathwork coaches. On the other, people looking for real, credentialed help rather than another meditation timer.
The timing was right. The UAE digital health market is projected to reach USD 2.65 billion by 2030, growing at 23.3% a year (Grand View Research) — one of the fastest-growing digital verticals in the Gulf. But market timing only matters if you can ship, and the founding team knew wellness, not software.
The situation
Marketplace products are deceptively expensive to build, because you are really building two apps that have to agree with each other.
Two apps, one product
The practitioner needs to set up a profile, publish credentials, define working days and hours, list what they offer, price it and get paid. The client needs to browse practitioners, trust what they see, find a slot that actually exists, pay in their own currency and show up to a video call that works first time. Every one of those is a feature, and getting any one of them wrong breaks the loop.
No engineering team, and a runway with an end date
Hiring a CTO and building a team would have cost months before a single screen shipped. In a market compounding at 23% a year, those months are expensive — and an open-ended time-and-materials bill is a real risk to a fixed runway, not a hypothetical one.
A scope far bigger than the first release
Booking, payments, video calls, courses, community, messaging, subscriptions — the full vision was large. Nothing gets validated until something real is in users’ hands, so the scope had to be sequenced to make the marketplace work end to end long before it was finished.
How we approached it
We didn’t quote a single number for “the app”. The engagement runs as a series of two-week sprints, each one fixed-scope and fixed-price, each one chosen by the founder.
1
We priced the roadmap before writing code
Every feature gets a point value based on complexity — a configuration change is small, a new screen is medium, payments or video is large, an admin dashboard larger again. Points are not billing hours; they are building blocks that let a founder without a technical background see the trade-offs directly.
“Should we do subscription billing or appointment booking first?” stops being an argument about engineering effort and becomes a straightforward choice between two known sizes. Each month buys a fixed number of points across two sprints, and the founder decides what fills them.
2
We shipped the marketplace loop first
The first sprints went to the chain that makes a marketplace a marketplace: onboarding → practitioner profile → browse → book → pay → session. Nothing else matters until that chain works, because until it does there is no product to learn from.
Both apps were built from one shared foundation rather than two separate ones. For a founder without a technical team that isn’t a technology preference — it is one team instead of two, and every new feature written once instead of twice over.
3
We kept building, sprint after sprint
The engagement didn’t stop at launch. Every sprint starts with a signed scope document, and when priorities shift mid-sprint — as they always do — there are three clear options rather than a renegotiation: swap an unstarted feature for the new one at the same price, queue it for the next sprint at no cost now, or, if it genuinely can’t wait, add it to the current sprint as an urgent add-on.
The founder keeps control of the roadmap. The budget stays predictable. Nobody has an awkward conversation about scope creep.
What we built
Eight months of fortnightly sprints, from a full rebuild to a live two-sided marketplace with its own admin back-office.
Dec 2025 – Jan 2026
Foundation
Complete rebuild of the app
A faster, more reliable backend
Sign-up, login and onboarding
Full redesign of every app flow
Dec 2025 – Jun 2026
Discovery & content
Home and Explore browsing
Practitioner and client profiles
Courses, plus a music and meditation library that keeps playing in the background
Favourites and playlist suggestions
Content creation tools for practitioners
Feb – Jul 2026
Booking & payments
1-on-1 scheduling against each practitioner’s real availability
Card payment in dirhams, with VAT shown before you pay
Refund policy acknowledged before payment, and a cancel-and-refund window straight after booking
24-hour reschedule cutoff, with refund rules by who cancels and when
Confirmation emails and a full record of every change
Dec 2025 – Feb 2026
Live sessions & community
Video sessions that run inside the app
Direct messaging between clients and practitioners
Community feed with posts, comments, likes and follows
Content reporting and blocking from day one
May – Jul 2026
Running the business
Admin back-office for onboarding, moderation and disputes
Practitioner certificate upload and verification
Earnings view and bank details for payouts
Session reminders and new-content alerts
Subscription paywall and account deletion
Throughout
Integrations
Payment gateway
Video provider
Push and email notifications
Auth and analytics
The booking and refund engine is where marketplaces quietly bleed money — every cancellation rule is enforced in the product and logged, so disputes are settled with evidence instead of goodwill.
The admin back-office is what lets the team run day-to-day operations themselves, instead of asking a developer every time.
One sign-up, two products: every new account declares which side of the marketplace it belongs to before anything else loads.
Browsing verified practitioners alongside the guided audio library. Names and faces are blurred — the practitioners are real people.
The results
30+ practitioners live on the platform
Each one onboarded and credential-verified, with their own working hours, pricing and payout details — the supply side of a marketplace, running.
A complete marketplace loop in production
Discover a practitioner, book a real slot, pay in dirhams with VAT, and take the session over live video — all inside the app.
Payments and subscriptions live
Card payments and subscriptions running in production, with the cancellation policy shown at checkout rather than buried in terms of service.
One app, every device
Live on iPhone and Android, built once rather than twice over — one team, one release cycle.
The team runs the business without us
An admin back-office handles practitioner onboarding, moderation, bookings and disputes — no more asking a developer for a report.
Still shipping, ten months on
New features have shipped on a fortnightly cycle throughout — the opposite of the build-and-abandon pattern that strands most startup apps.
Development spend known in advance
Every sprint scoped and priced before it starts, so the monthly figure is a decision rather than a surprise.
If you’re building something similar
Most of what made this build hard is not specific to wellness. If any of these describe what you’re planning, this is the same problem with different words on the screens.
Psychology, therapy and coaching platforms
Credentialed professionals, private sessions, sensitive data and a booking relationship that has to feel safe on both sides.
Clinic and practitioner booking
Real availability, reschedule rules and refunds enforced in the product.
Any two-sided marketplace with verified supply
Certificate upload, verification, earnings and payouts — the unglamorous half that decides whether a marketplace can actually operate.
Anything that takes payment for a booked time slot
Tutoring, fitness, legal and professional consultations, home services.
Questions people ask us
Before you build something like this
What does it cost to run once it’s built?
Running cost is driven by four things: hosting and database load, the third-party services you depend on (payments, video, notifications), app store and compliance overheads, and the pace at which you keep shipping. We size each of those with you before the build, so nothing arrives as a surprise — and we sequence the build so the expensive parts only switch on when there are users to justify them.
What happens after launch?
Most clients continue on a monthly partnership, and this one has. The marketplace went live and we have kept shipping on a fortnightly cycle ever since, with every sprint scoped and agreed before it starts. Launch is the point where the product starts teaching you things — stopping there is how apps get stranded.
Do I need a technical co-founder to build a wellness app?
No. This founding team knew wellness, not software. We provide the full product team — design, engineering, product and QA — and the founder keeps the roadmap and the decisions. Hiring a CTO and building a team first would have cost months before a single screen shipped.
How long does it take to build a two-sided marketplace app?
The marketplace loop — onboarding, profile, browse, book, pay, session — is what has to work first, and that is a matter of weeks rather than months. The full platform here reached production in eight months of fortnightly sprints, with the core loop live well before that.
Can you build for iPhone and Android at the same time?
Yes. Both apps here come from one shared codebase, which for a founder without a technical team means one team instead of two, and every new feature written once rather than twice over.
Building something similar?
Message us on WhatsApp — we’ll tell you whether we’re the right team for it, and what the first phase would need to cover.
More of our work
Other builds in this space
Case Study · Wellness & Healthtech
