GUDS
Case study · 2026Finding a worker for today and finding a job for years lived in different places. We built GUDS — one cross-platform app where both happen, with chat built in.
Overview
GUDS connects people who need work with people who need workers in Uzbekistan. Inside one app there are four products: job seekers browse vacancies and apply with a resume; employers post vacancies and search resumes; a client posts a one-day job and the app finds a worker nearby; and workers go online to receive those jobs in real time. A messenger links them all. We built the cross-platform React Native app, the Django backend behind it and the guds.inc landing site. The app is live on the App Store and Google Play, starting in Tashkent.
The challenge
Short-term work in Tashkent is arranged by phone calls and chat groups; steady jobs live on job boards. A client with a task today cannot see who is free nearby, and a worker cannot see what is on offer around them. The app had to work for both sides of both markets — and make a daily job feel as immediate as ordering a taxi.
- C1
Four apps in one install
Seekers, employers, daily clients and daily workers have different screens and flows, but share one login, one profile and one messenger.
- C2
Real time on a phone
Job offers, live tracking and chat must survive weak mobile networks, the app going to the background and battery limits.
- C3
Three languages
Every screen in Uzbek, Russian and English, with Uzbek as the default.
Our approach — decision logDecision log
One app, four products — each with its own navigation, all on the same account, chat and backend. Below: the decisions that shaped the system, and what each one cost.The decisions that shaped the system, and what each one cost.
| No. | Decision | Why | Trade-off accepted |
|---|---|---|---|
| D1 | A super-app shell that switches between mini-app navigators. | One install and one login for four products, and room to add delivery, shopping and food without a new app. | Each mini-app keeps its own navigation and cache, which needs care to stay consistent. |
| D2 | Taxi-style matching over WebSockets: workers stream location, offers arrive with a countdown. | A daily job should find someone within minutes, and the client should watch the worker approach on the map. | Location permissions, battery use and reconnects need careful handling: the socket backs off and reconnects, and the screen stays awake only while a worker is online. |
| D3 | React Native CLI with native modules and over-the-air updates, instead of a managed runtime. | Calls, push notifications, a wake lock and maps need native code; JavaScript fixes ship without waiting for store review. | The team maintains the iOS and Android builds itself. |
- D1
A super-app shell that switches between mini-app navigators.
- Why
- One install and one login for four products, and room to add delivery, shopping and food without a new app.
- Trade-off
- Each mini-app keeps its own navigation and cache, which needs care to stay consistent.
- D2
Taxi-style matching over WebSockets: workers stream location, offers arrive with a countdown.
- Why
- A daily job should find someone within minutes, and the client should watch the worker approach on the map.
- Trade-off
- Location permissions, battery use and reconnects need careful handling: the socket backs off and reconnects, and the screen stays awake only while a worker is online.
- D3
React Native CLI with native modules and over-the-air updates, instead of a managed runtime.
- Why
- Calls, push notifications, a wake lock and maps need native code; JavaScript fixes ship without waiting for store review.
- Trade-off
- The team maintains the iOS and Android builds itself.
Solution and architectureArchitecture
One React Native app, a Django API and WebSocket channels for chat and live jobs.
The app reads and writes through a REST API and keeps four WebSocket channels: chats, calls, and the client and worker sides of a daily job. Maps and address search come from Google; push notifications from OneSignal; wallet top-ups from Payme, returning to the app by deep link.
- Built by SwiftCore
- Existing or third-party system
- Single entry point for all clients
Technology
The tools in production on this project, and the reason each was chosen over the alternatives.
Frontend
- React Native
- TypeScript
- React Navigation
- TanStack Query
- Zustand
- MMKV
- Reanimated
React Native · TypeScript · React Navigation · TanStack Query · Zustand · MMKV · Reanimated
One codebase for iOS and Android, with fast local storage and smooth animated sheets and maps.
Backend
- Python
- Django
- Django REST Framework
- WebSockets
Python · Django · Django REST Framework · WebSockets
REST for screens and lists, WebSockets for chat, calls and live jobs.
Infrastructure
- Google Maps & Places
- OneSignal
- Payme
- Over-the-air updates
- Next.js (landing)
Google Maps & Places · OneSignal · Payme · Over-the-air updates · Next.js (landing)
Quality and tooling
- TypeScript
- Zod validation
- Three languages: uz, ru, en
TypeScript · Zod validation · Three languages: uz, ru, en
Inside the product
Results
Outcomes are still being measured.
We publish numbers only after they’ve been measured over a full period and approved by the client. Until then, here is what changed:
- Daily jobs and permanent jobs live in one app, with one account and one messenger.
- A client posts a job and sees a nearby worker accept it and approach on the map.
- Published on the App Store and Google Play, in Uzbek, Russian and English.