Digital Product · Mobile · SaaS
Building a multilingual support marketplace across mobile and web
A marketplace connecting people with mentors, coaches and support professionals, carried from product definition through architecture, mobile delivery and store publication.
Product definition
UX and multilingual experience
Solution architecture
Full-stack delivery
Release and store publication
The challenge
Mentor set out to connect people looking for support with the mentors, coaches and professionals able to provide it. A marketplace only works when both sides can find each other, so the hard part was never the directory: it was making a profile legible enough that someone could decide to make contact from it.
The product also had to work in English, Arabic and French. Multilingual support is often treated as a translation task added near the end. Here it shaped the data model and the layout from the beginning, because Arabic changes reading direction rather than only wording.
The approach
I structured the product around the decision a visitor is actually making—whether this particular person can help them—and worked backwards into the directory, search, filtering and profile detail needed to support it.
The platform decision followed from that rather than preceding it. Firebase gave authentication, a document model suited to varied professional profiles, server-side functions for the work that could not be trusted to a client, and hosting, without introducing infrastructure the product would have to carry a specialist to maintain.
What I delivered
A provider directory with search, filtering and structured professional profiles, contact actions, programmes, testimonials and community features, delivered as a React Native application through Expo for iOS and Android, with a Next.js web presence alongside it.
Around that sits the operational half that makes a marketplace runnable: administrative management of providers and content, push notifications, events and webinar workflows with registration and calendar handoff, and custom transactional email for the moments that matter—registration, confirmation and administrative notification.
Technical architecture
Authentication, data access and privileged operations run through Firebase, with Firestore security rules constraining access rather than the client being trusted to ask nicely. Work that must not depend on a device—notification fan-out, email triggering, administrative actions—runs in Cloud Functions.
Localisation is carried in the content model rather than bolted onto the interface, so a provider record is one record with language variants, not three records that drift apart. The later web and progressive web app work reused that same model rather than forking it.
Outcome
The product moved from an idea about connecting people to something publishable on the App Store and Google Play, with an administrative layer letting the people running it manage providers, events and communication without a developer in the loop.
Because the product, architecture and delivery decisions were made together, the web and progressive web app evolution extended the existing model rather than requiring a second build.
My contribution
- Product definition and information architecture
- UX flows across mobile and web
- Solution architecture on Firebase
- Full-stack development in React Native and Next.js
- Transactional email and notification design
- Store submission, review and release management
Technology
- Expo
- React Native
- Next.js
- Firebase Authentication
- Cloud Firestore
- Cloud Functions
- Firebase Hosting
- Push notifications
- SendGrid
- iOS
- Android
- PWA
A clear next step
Start with the decision in front of you.
Get preliminary direction first, or book a focused session when the question is ready.