At a glance. The case reports a 30-day build covering two interfaces and a shared backend. Acquisition for practitioners and customers then followed different, coordinated routes.
One marketplace, two different user needs
Holistic Unity brings together customers and practitioners offering holistic wellness sessions. The project described here covered a customer-facing iOS application and a web dashboard for practitioners.
Customers needed a mobile experience for discovering profiles, checking availability and booking. Practitioners needed a workspace for profile management, availability, bookings and session administration. The product had to connect both journeys through shared records and processes.
The delivery approach
- Shared specification: define the two user journeys and the common backend before building the interfaces.
- Unified backend: use a shared data model for profiles, calendar, payments and sessions.
- Parallel interfaces: build the native iOS app in Swift and SwiftUI alongside a React-based practitioner web application.
- Daily review: give the founder visibility of working builds and resolve product questions as development progresses.
Claude Code supported implementation. Product decisions, architecture review, testing and acceptance remained human responsibilities. The case reports delivery in 30 calendar days by two senior team members, with 27 user stories and daily founder reviews. Those figures describe this project; they are not a general delivery promise.
The customer application
- Discovery across ten wellness modalities, with category filters.
- Practitioner profiles with biographies, languages and relevant information.
- Availability, booking and payment flows.
- Integrated video sessions.
- Push reminders and follow-up notifications.
The practitioner dashboard
- Onboarding and review of submitted certification material before a profile is published.
- Editable profile, session types, prices and languages.
- Availability and calendar management.
- Payment and payout views.
- Session access and personal booking analytics.
Reviewing submitted credentials is a marketplace process. It should not be interpreted as a guarantee of clinical effectiveness or a substitute for regulated professional qualifications.
Supply and demand required different acquisition plans
For the practitioner side, the work focused on relevant one-to-one introductions through professional and social channels. Research considered the practitioner’s modality, active professional presence and the fit with the platform. Replies needed coordinated follow-up so one person would not receive conflicting messages on several channels.
WhatsApp was a possible continuation channel when the contact had agreed to use it. A response elsewhere was not treated as an automatic permission for promotional messages.
For customers, the plan combined search-oriented content and paid distribution. The website needed to explain the service and booking process clearly. Campaign and content outcomes should be measured through enquiries, bookings and acquisition economics rather than assumed traffic or conversion gains.
Reporting and ownership
Connected reporting used Make to help bring booking and acquisition information into dashboards for the founder. Reliable reporting depended on consistent events, record matching and a clear definition of each metric.
The case describes a client-owned code repository with a standard architecture. Documentation, access and handover matter alongside ownership so another team can maintain the product if required.
The roadmap described in the original case
The original project roadmap included additional modalities, English, Spanish and German localisation, an Android app, referrals and practitioner loyalty features. These were planned next steps in that account, rather than a claim that every item is now live.
The operational lesson is to treat the two sides of a marketplace as separate customer journeys while keeping the underlying product and records connected.