HomeCase studiesA Two-Sided Local Hiring Marketplace App Connecting...

Case study · Riyadh, Saudi Arabia

A Two-Sided Local Hiring Marketplace App Connecting Storefronts and Job Seekers

Recruitment technology — local, hourly and shift-based hiring for small and medium businesses

Local hiring runs on a card in a shop window and a walk-in at the wrong moment. Our team built a two-sided mobile marketplace that connects local businesses actively hiring with job seekers nearby — including a distinctive bridge between the two worlds: the business generates and prints its own QR-coded signage from inside the app, and a passer-by who scans it applies from their phone in minutes. The product was delivered first as native iOS and Android applications and later consolidated into a single cross-platform codebase serving both platforms.

Industry
Recruitment technology — local, hourly and shift-based hiring for small and medium businesses
Solution
A two-sided mobile marketplace: one application containing two complete experiences, one for hiring businesses and one for job seekers, integrated with a hosted API and web platform.
Platforms
Android · iOS · Cross-platform · Web & API
Stack
React Native · React · Java · Swift · Firebase · Google Maps
Location
Riyadh, Saudi Arabia · delivered remotely
Role
Engineering, with the team behind for mobile and QA

Delivered remotely for a business based in Riyadh, Saudi Arabia. Names withheld by agreement.

Project Overview

Industry: Recruitment technology — local, hourly and shift-based hiring for small and medium businesses.

Type of solution: A two-sided mobile marketplace: one application containing two complete experiences, one for hiring businesses and one for job seekers, integrated with a hosted API and web platform.

Business context: The mainstream job boards are built for professional, salaried recruitment. They serve a corner shop, a café or a small workshop poorly — the listing costs too much, the applicants are not local, and half of them are not real. Meanwhile the actual hiring signal in a local economy is physical: a sign in a window. It is visible only to people already walking past, produces no record, and interrupts the business at the busiest moment.

General users: Local business owners and managers hiring for shift and hourly roles, and job seekers looking for genuine work near where they live.

General purpose: To connect businesses that are hiring right now with candidates in their immediate area, and to make applying and reviewing applicants fast enough that both sides actually use it.

The Business Challenge

Local businesses were hiring blind. A card in the window reaches only passers-by, produces no candidate record, and invites walk-ins at whatever moment suits the candidate. Comparing applicants later is impossible because nothing was retained.

Job seekers could not tell who was actually hiring. Walking a high street tells you nothing about vacancies. General job boards are dominated by agency listings, stale posts and roles too far away to be practical for shift work.

Applying was disproportionately heavy. Formal application processes are designed for salaried professional roles. For hourly work, a candidate should be able to apply in minutes from a phone, and the business should be able to review just as quickly.

Nothing connected footfall to records. The people who came through the door in response to a sign were the most motivated candidates available, and the business had no way to capture them as anything other than an interruption.

Two audiences, opposite needs. Businesses need posting, applicant review, hiring actions and staff records. Seekers need discovery, profile building and application tracking. Shipping two separate apps would have doubled the cost and split an already small marketplace.

Two native codebases were slowing the product down. The initial delivery as separate native iOS and Android applications meant every feature was built twice, releases fell out of step, and the product could not iterate at the pace a marketplace needs.

Local means multilingual. Local hiring is exactly where language diversity is highest, so the application had to support multiple languages, including one written right-to-left, which affects layout rather than just wording.

Our Approach

One application, two experiences. We built a role-resolving application shell: after authentication, the app determines which side of the marketplace the user belongs to and mounts an entirely separate navigation tree, home screen and feature set. Both sides share the component library, networking layer and utilities, but neither carries the other's complexity.

Make the physical bridge a first-class feature. Rather than treating the QR code as a marketing add-on, we built the whole loop into the product: the business generates its code, composes it into printable signage on the device, prints or shares it directly, and receives the resulting scans as recorded visitors. No back-office print pipeline, no separate tool.

Design for the phone in the aisle. Both sides of this marketplace are used standing up, briefly, in the middle of doing something else. Screens were designed to be completed in short interactions, with document handling, phone verification and applications all achievable in one sitting.

Consolidate to a cross-platform codebase. Having delivered the product natively on both platforms, we rebuilt it as a single cross-platform application preserving the feature set — including the map, camera, printing, file handling and push notification capabilities that are usually cited as reasons not to go cross-platform.

Enable fast iteration. Over-the-air update capability was built in, so improvements and fixes reach users without waiting on an app-store review cycle — which matters disproportionately for a young marketplace responding to early feedback.

Build internationalisation in from the start. Multi-language support, including a right-to-left language, was designed in rather than retrofitted, because right-to-left support added later means revisiting every screen.

The Solution

For businesses

Job posting and lifecycle management. Businesses post roles and manage them through their full lifecycle — editing, suspending, closing and re-listing — so a listing reflects whether the business is genuinely hiring right now, which is the platform's core promise.

Applicant review. Applications arrive in the app with the candidate's profile, past positions, languages and CV, so a business can review candidates properly instead of judging by whoever walked in.

Hiring and staff records. Businesses record hires and end-of-employment through the app, maintaining a current employee list connected to the roles that produced them.

Printable QR signage generated in-app. The business generates its QR code, the app composes it into signage on the device, and it can be printed directly to a printer or shared as a document. The shop window sign becomes an entry point to the platform rather than a dead end.

Visitor capture. Scans from that signage are recorded as visitors with detail, giving the business a record of the interest its physical presence generated.

Direct candidate contact. SMS can be sent to candidates from the platform, so a business can move quickly without leaving the app.

Notifications. Businesses are alerted to applications and activity so time-sensitive interest is not lost.

For job seekers

Verified registration. Sign-up is confirmed by SMS code with international phone number handling, keeping the candidate pool real.

Profile and CV. Seekers build a reusable profile — past positions, languages and a CV document — so applying to the next role takes seconds rather than starting over.

Location-aware discovery. Available roles are browsed with location context and mapping, so "near me" means genuinely near, which is what determines whether shift work is viable at all.

Business directory. Seekers browse participating businesses directly, not just individual listings.

One-tap application. Applying submits the existing profile and CV, with the ability to withdraw an application afterwards.

Application tracking. Applied and archived lists let a seeker see where they stand, with the ability to nudge a business for a follow-up.

Scan to apply. A code seen in a shop window is scanned in the app, connecting the seeker directly to that business.

Multi-language and appearance support. The app ships in multiple languages including a right-to-left language, and adapts to the device's light and dark appearance.

Key Features

Role-resolved dual experience in one app A single application that presents two complete, separate products — one for hiring businesses and one for job seekers — resolved at authentication, sharing infrastructure without sharing complexity.

In-app QR signage generation and printing Businesses generate their code, compose it into printable signage on the device, and print or share it directly — turning the shop window into a working entry point to the platform.

Scan-to-connect visitor capture A seeker scanning a business's code is recorded as a visitor, giving the business a record of the interest its physical presence produces.

Full job lifecycle management Post, edit, suspend, close and re-list, so listings reflect current reality rather than accumulating as stale posts.

Applicant review with structured profiles Applications carry the candidate's past positions, languages and CV, enabling genuine comparison instead of first-come-first-served.

Hiring actions and staff records Hire and end-employment actions maintain a current employee list linked to the roles that produced it.

SMS-verified registration with international phone handling Phone verification at sign-up with proper international number parsing, formatting and validation, keeping the candidate pool credible.

Location-aware job discovery with mapping Roles are discovered with location context and map display, so proximity — the deciding factor in shift work — is visible immediately.

Reusable seeker profile and CV handling Document capture, storage and upload, so applying to subsequent roles takes seconds.

Multi-language support including right-to-left Localisation designed in from the start, with layout handling for a right-to-left language rather than translated strings alone.

Technical Architecture

Application shell. A single entry point that establishes session state, determines the user's role and mounts the corresponding navigation tree. Business and seeker experiences are structurally separate below that point.

Navigation layer. Role-specific stack and tab navigators, plus an imperative navigation service that allows navigation to be driven from non-UI contexts such as push notification handlers.

Shared component library. Common interface elements — alerts, confirmations, headers, loading states — shared across both experiences for consistency and to avoid divergent behaviour.

Networking layer. A single module exposing verb-level request helpers over the platform networking API, including multipart form handling for document and image upload, so screens express intent rather than transport detail.

Device capability layer. Camera-based code scanning, image selection, geolocation, map rendering, file system access for documents, view capture and print/share output, and push notification registration and handling — each isolated behind utility modules.

Localisation layer. Translation resources per supported language with device-locale detection, including right-to-left layout handling.

Release delivery. Over-the-air update capability alongside standard store distribution, enabling fixes to reach users without a review cycle.

Backend integration. A hosted REST API providing accounts, job lifecycle, applications, visitor records, notifications and SMS dispatch, with a companion web platform.

Flow: Mobile app (role-resolved shell) → Shared networking layer → Hosted REST API → Job, application, visitor and account data → Push and SMS delivery back to both sides of the marketplace

Technology Stack

Category Technology
Cross-platform framework React Native with Expo modules
Navigation React Navigation (stack + bottom tabs), role-scoped
Push notifications Firebase Cloud Messaging with native iOS push handling
Maps & location React Native Maps, device geolocation, location services
QR handling Barcode scanning for reading; SVG-based QR generation
Printing & documents View capture, image-to-PDF conversion, native printing, share sheet
File handling React Native file system access for CV documents
Localisation Multi-language resources with device locale detection and right-to-left support
Phone handling International phone number parsing, formatting and validation
Appearance System light/dark mode support
UI & interaction Reanimated, Gesture Handler, Screens, Safe Area Context, keyboard handling
Release delivery Over-the-air updates alongside store distribution
Testing Jest
Earlier native iOS generation Swift, AFNetworking, SDWebImage, Google Maps & Places, QR generation
Earlier native Android generation Java, Retrofit + Gson, Glide, EventBus, Play Services (Maps, Location, Places), QR reader/generator

Technical Challenges & Solutions

Challenge Our Approach
Two audiences with opposite needs in one product A role-resolved application shell mounting entirely separate navigation trees and feature sets after authentication, sharing components, networking and utilities — one binary, two coherent products, without either side carrying the other's complexity.
Bridging a physical shop window to a digital application The full loop implemented on-device: QR generation, composition into signage via view capture, conversion for print and PDF, direct printing and sharing, and scan handling on the seeker side that records the visit against the business. No back-office print infrastructure required.
Delivering camera, maps, printing, file handling and push in a cross-platform codebase Each device capability isolated behind a dedicated module with platform-specific handling where required, so cross-platform delivery did not force feature compromises relative to the native generation.
Migrating a mature product from two native codebases to one Rebuilt cross-platform with feature parity as the explicit constraint, preserving the existing API contract so the backend was unaffected — roughly halving the ongoing cost of every future change.
Right-to-left language support Localisation and layout direction handled from the start with device locale detection, rather than retrofitted — avoiding a full-application layout revisit later.
International phone entry feeding SMS verification Dedicated parsing, formatting and validation of international numbers at the input layer, so verification codes reach real numbers and format inconsistencies do not silently fail registration.
CV documents on mobile devices Device file system handling for capture and storage, with multipart upload rather than encoded payloads, keeping uploads efficient on mobile connections and documents manageable on device.
Needing to iterate faster than app-store review allows Over-the-air update capability built in, so fixes and refinements reach users immediately while substantive releases follow the normal store process.
Navigating from outside the UI, such as from a notification tap A navigation service exposing imperative navigation, so a push notification can route directly to the relevant job or application.

Security & Reliability

Verified registration. Sign-up is confirmed by SMS code with validated international phone numbers, which raises the cost of creating fake accounts on both sides of the marketplace.

Authenticated API access. Sessions are established through the platform API with token-based authorisation for user-scoped operations, and password recovery flows are provided for both roles.

Role separation. Business and seeker experiences are separated structurally, so each user's interface exposes only the operations appropriate to their side of the marketplace.

Permission-gated device access. Camera, location, photo library and notification access are requested at the point of use, in context, rather than demanded up front.

Controlled document handling. CV documents are uploaded as multipart data and can be deleted by the owner, keeping the user in control of their own material.

Release safety. Over-the-air updates allow a defect to be corrected within hours rather than waiting on a review cycle — a meaningful reliability property for a live marketplace.

Scalability & Performance

Scoped list fetching. Each list — available roles, applied roles, archived roles, received applications, visitors — is fetched for its own scope rather than as one dataset, so screens stay fast as activity accumulates.

Location-bounded discovery. Proximity filtering naturally bounds result sets, which keeps the discovery experience both relevant and light.

Efficient media handling. Images and documents are processed on device and uploaded as multipart data rather than inflated encodings, reducing payload size and upload time on mobile networks.

Role-scoped initialisation. Only the active role's navigation stack and screens are mounted, so the application initialises the experience in use rather than the whole product.

Targeted use of heavy components. Map rendering is confined to the discovery screens that need it rather than being carried across the application.

Cached imagery. Remote images are cached to avoid repeated fetching of business and profile media across sessions.

Business Outcomes

  • Businesses reach candidates beyond passers-by, while still capturing the passers-by they were already getting.
  • The shop window becomes a working channel, with printed signage generated in-app and the resulting interest recorded rather than lost.
  • Applicants can be compared properly, because applications arrive as structured profiles with work history and a CV rather than as interruptions.
  • Seekers can find genuinely local work, with proximity visible up front instead of buried in a listing.
  • Applying takes minutes, because the profile and CV are built once and reused.
  • Both sides act on time-sensitive interest, through push notifications and direct SMS contact.
  • The product reaches more people in more languages, including right-to-left support that many competing products lack entirely.
  • Ongoing development costs materially less, following consolidation from two native codebases into one cross-platform codebase with feature parity.
  • Improvements ship faster, thanks to over-the-air update delivery alongside store releases.

Why it worked

Marketplace products are unforgiving. They need two audiences served properly, they need to be genuinely fast to use because neither side is sitting at a desk, and they need to iterate quickly while the model is still being proven. Building that as two separate native applications is how young marketplaces run out of runway.

Our team delivered both generations of this product — the native applications first, then the cross-platform consolidation — with feature parity as a hard constraint rather than an aspiration. That included the capabilities usually cited as reasons cross-platform will not work: camera-based scanning, maps and geolocation, document handling, device printing, and push notifications. Delivering those in one codebase is the difference between a product that can afford to keep improving and one that cannot.

We also build the distinctive parts properly rather than approximating them. Generating a QR code is trivial; composing it into printable signage on the device, driving a printer from a phone, and closing the loop so a scan in a shop doorway becomes a record in a business's account is the feature that makes this product different from a job board. That is the work worth doing well.

Our teams cover native iOS and Android, React Native, mobile device capabilities, API integration, internationalisation including right-to-left layout, and app-store delivery with over-the-air update strategies — the full span a mobile marketplace product needs across its life, not just at launch.

Final Summary

Local hiring has always been a mismatch between how businesses signal that they are hiring and how candidates look for work. The signal is physical — a sign in a window — visible only to people already walking past, producing no record and interrupting the business at the worst moment. The search is digital, but the platforms available are built for salaried professional recruitment and serve hourly, local hiring poorly.

Our team built a two-sided mobile marketplace that addresses both ends and connects them. Businesses post and manage roles, review structured applications, record hires and maintain staff lists — and generate their own QR-coded signage inside the app, printed directly from the device, so the shop window becomes an entry point rather than a dead end. Seekers register with verified phone numbers, build a reusable profile and CV, discover genuinely nearby roles on a map, apply in minutes and track where they stand. A scan in a doorway becomes a recorded connection between a passer-by and a business that is actually hiring.

Technically, the product spans two generations: native iOS and Android applications first, then consolidation into a single cross-platform codebase with full feature parity — camera, maps, geolocation, document handling, printing and push notifications all preserved. Alongside that sit multi-language support including right-to-left layout, verified international phone handling, and over-the-air update delivery for rapid iteration. For a marketplace, that combination — two audiences served properly, distinctive features built properly, and a codebase that can keep changing affordably — is what determines whether the model gets the chance to prove itself.

01 — Questions

asked about this kind of project

How do you build a two-sided marketplace app?

Serve both sides properly, but do not build two products. A role-resolving application shell decides at authentication which experience to mount, and each side gets its own navigation, home screen and features while sharing components, networking and utilities. The alternative — two separate apps — doubles development and support cost and splits a marketplace that is usually fighting for critical mass in the first place.

Should a marketplace app be built natively or cross-platform?

Cross-platform is the default for a marketplace, because iteration speed and cost of change matter more than the last few percent of platform polish. The common objection is device capability, and it is largely outdated: camera scanning, maps, geolocation, file handling, printing and push notifications are all achievable in a cross-platform codebase. Native remains justified for graphics-intensive applications or deep platform integration — which most marketplaces are not.

Can you migrate existing native iOS and Android apps to React Native?

Yes, and it is a common and sensible move once a product has proved its shape. The approach is to rebuild against the existing API contract with feature parity as an explicit constraint, so the backend is untouched and users lose nothing. The return is straightforward: every subsequent feature is built once instead of twice, and platform releases stop drifting apart.

How can a mobile app connect a physical business location to digital users?

QR codes remain the most practical bridge, provided the whole loop is built. The business should be able to generate its code, produce the physical artefact and put it up without leaving the app — which means on-device composition of printable signage and direct printing or sharing. On the other side, a scan should create a real record connecting that person to that business. A code that merely opens a website is a missed opportunity.

How do you implement location-based discovery in a mobile app?

Request location permission in context, at the moment discovery is used, and combine device geolocation with server-side proximity filtering so the result set is bounded before it reaches the device. Present results with a map view where physical proximity is what the user is actually judging. For local and shift-based use cases, distance is frequently the deciding factor, so it belongs on the primary screen rather than in a detail view.

How do you support multiple languages, including right-to-left ones?

Build it in from the start. Text translation is the easy half; the harder half is layout direction, which affects navigation, alignment, iconography and gesture direction throughout the application. Retrofitting right-to-left support means revisiting every screen. Designed in from the beginning, it costs comparatively little and opens markets that competitors frequently ignore.

How can updates reach users without waiting for app-store review?

Over-the-air update mechanisms let JavaScript-layer changes ship directly to installed applications, so a defect can be corrected in hours rather than days. Native changes still require a store release, and store policies set boundaries on what may be delivered this way — but for a young product responding to real user feedback, the difference in iteration speed is substantial.

What does it take to build a marketplace app like this?

Scope drives the estimate, but the sequencing matters more than the total. Build accounts and the two role experiences first, then the core transaction — posting and applying — then discovery, then the distinguishing features. Marketplaces need to be in real users' hands early, because the model's assumptions about both sides are usually wrong in at least one respect, and finding out which one is the most valuable thing the first release does.

03 — Similar project?

describe what is different about yours

Build yours.

Tell me what exists, what you need and the deadline. Fixed price for a defined scope, or hourly from $10 with a written estimate first.

Ahmedabad, India · IST (UTC+5:30) · --:-- IST · Mon–Fri 09:00–18:00 IST · US & EU overlap daily

No newsletter, no CRM. Just a reply.