01
Two kinds of user
Problem
Travelers and local businesses want completely different things from the app.
How we solved it
Separate flows: trips and discovery for travelers, hours, radius and booking management for providers.
Case study · 18Services Marketplace
Roam at Will (R@W)
A marketplace for people who live on the road, matching vanlifers, RVers and nomads with trusted local services wherever they stop.
- Client
- Roam At Will, LLC
- Industry
- Travel · Local Services Marketplace
- Platform
- iOS · Android · Web
- Timeline
- 18 weeks
- Outcome
- Local services you can find and book from wherever you've parked
- 25 miStarting radius for nearby search
- 3Platforms shipped from shared code
- 18 wksFrom kickoff to launch
01
Overview
Roam at Will is a services marketplace for people without a fixed address: vanlifers, RV owners, long-term travelers and remote workers. They plan trips, find mechanics, cleaners and other local pros near their next stop, book them and leave reviews. We delivered the app for iPhone, Android and web from one Flutter codebase, plus the admin panel.
02
The challenge
Service marketplaces assume you live where you search. Someone pulling into a new town tonight has no trusted plumber, mechanic or cleaner, and their dates keep moving. Providers, for their part, want customers passing through, not only locals. Roam at Will needed to fit travel plans and provider availability together around location.
03
Our approach
We made the trip the anchor. Travelers search around where they are or will be, and providers describe when and how far they'll travel, so matches account for both sides' plans.
04
How we built it
3 steps, from architecture to launch.
- 01
Shared code for every device
A single codebase ships to iPhone, Android and web, with a React panel for operators.
- 02
Search by radius
Discovery starts at 25 miles and can be widened, using Google Places for addresses.
- 03
Firebase underneath
Firestore data, Cloud Functions, FCM notifications and Firebase Hosting run the backend.
05
Problem → How we solved itTechnical challenges
02
Moving dates against fixed hours
Problem
A traveler's arrival date changes, while a provider has working hours and a service area.
How we solved it
Trips store arrival and departure dates, and providers set hours, recurring availability and radius.
03
A booking that can be negotiated
Problem
A simple request-and-accept flow breaks as soon as the time doesn't suit.
How we solved it
Bookings support requests, acceptance, decline, counter-proposed times, completion and cancellation.
06
6 screensScreens
07
5 featuresWhat we shipped
- 01
Trips
Add stops with arrival and departure dates and see services near each one.
- 02
Find a pro
Browse by profession and specialty within an adjustable radius, or ask for a new category.
- 03
Book and reschedule
Send requests, receive counter-offers on timing and track each booking.
- 04
Chat and reviews
Message providers, then rate the job; ratings roll up on each profile.
- 05
For businesses
Set hours, availability and travel radius, with sponsored cards and push alerts managed from the admin.
08
Tech stack
- Flutter + Dart
- iOS, Android and web app
- React
- Admin panel
- Firebase
- Data, Cloud Functions and Hosting
- FCM
- Push notifications
- Google Maps + Places
- Location search and discovery
Tell us what you are shipping.
Start a Project →