Soulthing — Designing an
At-Home Wellness Ecosystem from Zero to One
Soulthing began with a simple but powerful question from Haridwar-based founder Aditya Shivpuri.
Why should quality therapy and wellness care be limited to clinics when it can come directly to your home?
Most wellness platforms focused on spa appointments. Soulthing was different. It needed to bring trained and verified therapists into customers' homes while managing safety, scheduling and recurring sessions.
I worked closely with founder Aditya Shivpuri to shape the product from the ground up — from booking logic and user experience to therapist operations and product structure.
The Challenge
Soulthing was not just another booking app.
Every session involved real people, home addresses, therapist travel, safety, payments and ongoing care.
We had to answer questions like:
- How can users trust a therapist before the first visit?
- How should therapists be matched with each booking?
- What happens when a therapist is late or unavailable?
- How do rescheduling and cancellations work?
- How can users manage multi-session packages?
- How do we keep the experience simple for both users and therapists?
Every design decision affected customers, therapists, and the operations team.
My Role
Product Design
- Product Strategy
- UX Research
- User Experience
- Information Architecture
- Wireframes and Prototypes
- Visual Design
- Design System
- Product Documentation
Beyond Design
- Product Structure
- Booking Logic
- Backend Flow Mapping
- Customer Journey
- Therapist Journey
- Operations Workflow
- GTM Workshops
- Scalability Planning
This project required me to think like a product designer, product manager, and systems thinker at the same time.
Understanding the Ecosystem
Before designing screens, we mapped how the entire service would work.
- Booking Management
- Zone Allocation
- Travel Buffers
Major Challenges
Building Trust Before the First Session
“Inviting a therapist into your home requires trust.”
We added therapist profiles, verification details, experience, gender information, and clear session guidelines to help users feel confident before booking.
Creating a Real Booking System
“A booking could not depend on an available time slot alone.”
The system also had to consider location, travel time, therapist skills, equipment and schedule buffers.
Designing for Two Users
“Customers wanted a quick and simple booking experience.”
Therapists needed clear schedules, customer details, navigation, safety controls, and earnings information. Both experiences had to work together.
Standardising an Offline Service
“Therapy needs can vary from person to person.”
We converted these open-ended services into clear packages with defined durations, pricing, and session expectations.
Managing Multi-Session Packages
“Many treatments require more than one session.”
Users needed to track completed sessions, manage upcoming bookings and reschedule one session without affecting the full package.
Competitive Analysis
We studied healthcare, wellness, and home-service platforms to understand common patterns and gaps. The research helped us identify opportunities around trust, service clarity, therapist information, and recurring bookings.
| Brands | Mental Therapy | Physical Therapy | Home-Based | Program-Led | Primary Focus |
|---|---|---|---|---|---|
| Amaha (amahahealth) | ✓ | × | Partial | × | Mental health (digital + clinics) |
| Momskidcare | × | ✓ | Partial | ✓ | Clinical home healthcare |
| Imumz | × | × | × | ✓ | Eldercare & support services |
| Apollo Homecare | × | ✓ | ✓ | × | Hospital-grade home care |
| BetterHelp | ✓ | × | × | ✓ | Online mental therapy |
| Soulthing Company | ✓ | ✓ | ✓ | ✓ | Integrated home-based therapy |
We found opportunities to create a better experience than existing platforms.
Beyond UI Design
Good product design is not only about screens. Before building the interface, we mapped the logic behind bookings, therapist allocation, payments, cancellations, session tracking, and customer support.
Once the product logic was clear, designing the experience became much easier.
Turning Complexity Into Product Decisions
Mapping the system was only the first step. The harder part was deciding how customers, therapists, and operations should behave when real-world situations did not follow the happy path.
Instead of treating these as edge cases, we designed them into the product logic from the beginning.
Matching the Right Therapist
Problem
A booking could not simply be assigned to any available therapist.
Constraint
- Service expertise
- Customer location / service zone
- Availability and existing bookings
- Travel feasibility
- Required equipment
- Customer preferences where applicable
Decision
Eligibility first, availability second.
When a customer books a service, the system first creates a pool of therapists who are qualified to deliver it.
That pool is then narrowed before anyone receives or is considered for the booking.
- 1Service expertise
- 2Serviceable zone
- 3Therapist availability
- 4Existing booking schedule
- 5Travel feasibility
- 6Relevant customer preferences
Trade-off
Complete freedom to select any therapist would create a stronger feeling of control, but also more availability failures and operational complexity.
For the initial product, we prioritised reliable fulfilment over unrestricted selection. Customers would still see their assigned therapist before the session.
Expected result
A simpler booking experience for customers while keeping therapist allocation flexible enough for operations.
Designing Beyond the Happy Path
Problem
A booking request does not guarantee that a therapist will accept it.
Constraint
- A therapist may be unavailable or miss a request
- The journey may fall outside a practical travel radius
- Another booking may create a conflict
- A therapist may reject the job
- The customer should not have to understand this complexity
Decision
Separate the customer booking state from the therapist assignment state.
The customer creates one booking request while therapist allocation continues independently behind the scenes.
If the first eligible therapist does not accept, the same booking can move to another eligible therapist without asking the customer to restart checkout. If automated allocation cannot fulfil it, the request moves into an operations-assisted state.
Operations override
- Assign another therapist
- Resolve availability conflicts
- Contact the customer
- Reschedule the session
- Handle exceptional cases
Trade-off
This creates additional backend states and more operations complexity.
But it prevents internal fulfilment problems from becoming customer problems.
Expected result
The customer experiences one booking, even if multiple assignment attempts happen behind the scenes.
Availability Is More Than an Empty Slot
Problem
Two sessions may look available on a calendar while still being impossible for the same therapist to complete.
Constraint
- Distance between consecutive bookings
- Previous booking location
- Service zone
- Time of day
- Local operating conditions
Decision
Session time + travel feasibility + existing schedule.
Therapist availability checks more than whether a calendar slot is empty. It also prevents bookings that would create unrealistic back-to-back schedules.
Configurable travel buffer
Travel time is an operationally configurable value rather than one universal fixed number, so it can adapt to each service context.
Trade-off
The system may show fewer theoretically available slots.
In exchange, the slots it does show are more likely to be operationally achievable.
Expected result
Designed to create more realistic therapist availability and fewer schedule conflicts or late arrivals.
Choice vs Reliable Fulfilment
Problem
Letting users choose a therapist sounds ideal from a customer-experience perspective.
Assumption
More therapist choice could increase trust and customer confidence.
Constraint
- A preferred therapist may be unavailable
- They may be outside the service zone
- Nearby or distant bookings may make the timing impractical
- They may not be suitable for the requested service
- Their availability may change after booking
Decision
Build the initial booking around service + location + date + time.
The platform handles therapist allocation instead of making a specific therapist a hard dependency.
Once assigned, customers can see relevant therapist information before the session so trust is still established.
Trade-off
Users have less control over exactly who provides the service.
In exchange, the system gains significantly more flexibility to fulfil the booking reliably.
Expected result
Higher operational flexibility without hiding therapist identity from customers.
One Package, Multiple Independent Sessions
Problem
Therapy often requires more than one session, but a three-session package should not behave like one large booking.
Constraint
- A customer may need to reschedule only one session
- A therapist may become unavailable for one session
- Completed and future sessions must keep their own state
- The remaining package balance must stay intact
Decision
Treat the package and every session inside it as separate product entities.
Each session maintains its own date, time, status, therapist assignment, session report, and rescheduling state.
If Session 2 changes, Session 1 remains completed, Session 3 remains unaffected, and only Session 2 returns to rescheduling. Therapist allocation can run again when required.
Example: 3-session package
- Session 1 — Completed
- Session 2 — Upcoming
- Session 3 — Not scheduled / Upcoming
Trade-off
This creates more backend complexity than treating a package as one booking.
However, it matches how recurring therapy actually happens in the real world.
Expected result
Users would be able to manage recurring care without one scheduling change breaking the entire package.
Automation With a Human Safety Net
Problem
Home-service products eventually encounter situations that cannot be resolved perfectly through predefined UI states.
Constraint
- Therapist cancellations
- Customer emergencies
- Location problems
- Reassignment and schedule conflicts
- Payment exceptions
Decision
Include an operations layer that can intervene when necessary.
Soulthing was not designed as a completely automated marketplace. Predictable workflows can be automated while people remain available for exceptions.
Operations can support
- Booking management and therapist allocation
- Reassignment and rescheduling
- Customer support
- Refund / cancellation handling
- Service-zone management
Trade-off
Manual intervention is less scalable than complete automation.
But premature automation would create a brittle early-stage product before enough operational data exists.
Expected result
Creates the foundation to automate predictable workflows safely while keeping human support available for exceptions.
The goal was not to eliminate operational complexity. It was to keep that complexity behind the system so the customer experience could remain simple.
From Strategy to Execution
After defining the product structure, we moved into design execution.
We studied similar platforms, understood user needs, and mapped the complete customer and therapist journeys.
We then created wireframes, tested the key flows, and built the final visual experience.
User Journey Map
Users We Chose to Serve First
Final UI Designs
Once the structure was clear, we created a clean and calming interface for the platform.
The design system helped keep components, colours, spacing, and interactions consistent across the customer and therapist experiences.
User App
Vendor App
Every screen was supported by clear product logic, not just visual design.
Current Status
Soulthing is currently in development.
So I'm intentionally not attaching polished growth metrics to the project yet. The work so far has taken Soulthing from an early service idea to a structured product system covering customer booking, therapist operations, recurring sessions, fulfilment logic, and the operational workflows needed to support them.
The next real test is not another Figma screen — it is seeing how these decisions hold up once the product meets real customers, therapists, and day-to-day operations.
The foundation is in place. Now I'm looking forward to seeing what works, what breaks, and what we learn as Soulthing moves towards launch.
Designed from assumptions. Built for validation.
Key Takeaway
Great product design is not only about making things look good.
It is about understanding people, solving real operational problems, designing scalable systems, and building products that can grow sustainably.
With Soulthing, the goal was not just to design an app — it was to build the foundation of an entire at-home wellness ecosystem.
