Case Study
Service Space
Local services marketplace — book a trusted provider from your phone
01Problem
Booking a trusted local service provider on a phone usually means scattered calls, no real-time availability, and no accountability once a job is booked. Service Space set out to make discovering, booking, and paying a local provider feel as direct as ordering a ride.
02Constraints
- A founder timeline: the goal was an MVP real users could actually book through, not a throwaway prototype.
- A two-sided marketplace — the customer app and the provider app had to ship together for either to be useful.
- Mobile-first: the entire journey, including payments and messaging, had to work on a phone.
- Solo build — product scoping, the React Native app, the Node.js API, and deployment were all mine.
03Approach
- Led the core booking experience end-to-end: service browsing, provider profiles, and real-time booking on a mobile-first layout.
- Shaped the backend API design and owned frontend integration for availability, reviews, and in-app messaging.
- Built the provider side as well — job management, availability control, and booking responses — so both halves of the marketplace were usable.
The product decisions came from watching real people use it, not from assumptions.
- Ran usability testing with 40+ users and fed the findings straight back into navigation, layout, and form design — this was the loop that shaped the booking flow, not a one-off review.
- Prioritized the browse → book → pay path first; provider-side depth and messaging followed once the core loop tested well.
- Kept the data model deliberately lean — enough to support real booking behavior without over-engineering an early MVP.
04Architecture
A React Native client against a Node.js / MySQL API, with third-party services handling the parts not worth building from scratch.
- ▸React Native — one codebase for iOS and Android
- ▸Node.js API — booking, availability, reviews, messaging
- ▸MySQL — providers, bookings, and reviews
- ▸Stripe — in-app payments
- ▸Twilio — SMS booking notifications
05Decisions & Tradeoffs
Used Stripe for in-app payments instead of building a payment/escrow layer.
↳Reached a trustworthy checkout faster and offloaded PCI burden, at the cost of Stripe fees and less control over payout timing.
Sent booking notifications over Twilio SMS rather than push-only.
↳Reaches users who do not have the app open and needs no notification opt-in, but adds a per-message cost.
Validated the full flow in a staging environment before release.
↳A slower path to “live,” but payment, messaging, and booking edge cases were caught before real users hit them.
06Outcome
Shipped
- A working two-sided booking marketplace: customers browse, book in real time, pay in-app, and message providers.
- Provider workflows for job management, availability, and booking responses.
- Stripe payments and Twilio SMS, fully validated in staging.