(Case study · 03)
AutoJobs
Dealership jobs in Lucknow were posted on a website that most candidates only ever opened on a phone. AutoJobs puts the whole loop in one Android app: a candidate finds a sales or service job, applies in one tap and watches the application move; the dealership posts, reviews and shortlists from the same app. It talks to the portal's existing server, so nothing about the business had to change.
Built for AutoJobs (autojobs.in), a job portal for auto dealerships in Lucknow. The screens shown use the app's own test accounts, not real candidates.
(Why this app)
How do you turn an existing backend into a phone app people actually use?
AutoJobs already had a website, a server and a list of 137 dealership job roles. What it didn't have was a way in for the people it was for.
Most candidates for sales and service jobs at dealerships live on their phones, often small Android ones, and many are more comfortable in Hindi. Applying, and then finding out what happened, usually meant calling the dealership.
So the job wasn't to invent a new system. It was to make the one that existed usable in someone's pocket, without changing how the business runs.
(What I looked at)
Before I designed a screen
This research is real and came first: written on 25 September 2026, before the app was built, from the live site, its production code and read-only calls to its public API. No login was used.
- The live website and its code
- What does the business actually do online? 55 pages, 118 server endpoints, live employer plans.
- The 137 job roles
- What do candidates search for? Sales, service, accounts, CRM, and so on, the vocabulary of a dealership.
- Google Play policies
- What will Play reject? Website-in-a-shell apps, missing account deletion, unclear data use.
- Other job apps
- What do these candidates already expect? Phone OTP sign-in, Hindi, quick apply.
| Who | What it is | What it meant for AutoJobs |
|---|---|---|
| EyeQAutojobs | An automobile-sector job portal in India | The closest direct competitor |
| apna · WorkIndia · Job Hai | Mass hiring apps with vernacular UI and phone-first sign-up | Not dealership-specific, but they set the expectation: OTP login, Hindi, quick apply |
| Naukri · foundit · Indeed · LinkedIn | General job boards | Expensive for small dealers and not role-specific |
| autojobs.com | A US car-dealership job board with a near-identical name | A naming risk: the store title needed to say India |
A summary of the research document, not a new audit.
(What changed because of it)
Finding, decision, screen
From the research notes · each one is in the shipped app
Most candidates are phone-first, often on small Android phones, and prefer Hindi.
English and Hindi from day one. Every screen checked down to 320 dp, light and dark.
Hindi screens
Google Play rejects apps that are just a website in a shell, and the site was built for desktops.
A real native app with Expo and React Native, not a wrapper.
The whole app
Employer credits are digital goods, and Play's billing rules apply to them.
No purchase inside the app in v1. Plans stay on the website.
Dealership side
Candidates had to call to find out what happened.
Applied, in review, shortlisted, as a track you can see.
Application status
(Information architecture)
Two apps inside one install
A candidate and a dealership want opposite things, so each gets its own home behind one login screen. Nothing on the candidate side asks them to understand hiring, and the dealership side stays small.
These are the app's real routes.
AutoJobs
- Candidate
- Home
- Jobs
- Job page: details · apply · share · save
- Applied
- Application: status track
- Saved
- Profile: resume · photo · language · theme
- Dealership
- Sign in
- Dashboard
- Post a job
- Job: applicants · shortlist · reject · call
- Everyone
- Onboarding: role · city · experience
- Sign in · register · forgot password
- Company page
- Delete account
Who it's for
- Candidate Find, apply, track, save
- Dealership Post, review, shortlist, call
- Guest Browse jobs before signing up
(Flows)
Three journeys that had to work
01 · Candidate
- Onboarding
- Role and city
- Jobs, filtered
- Job page
- Apply in one tap
- Applied
- In review
- Shortlisted
02 · Dealership
- Sign in
- Post a job
- Applicants
- Shortlist or reject
- Call
03 · Release
- Signed .aab
- Internal testing
- Closed test, if the account needs it
- Store review
- Production
(Scope)
What made v1, and what waited
The research split v1 in two: the candidate side complete, the dealership side lite. Everything else went on a written v2 list, so the app could ship instead of growing.
Payments stayed out on purpose. Selling credits inside an Android app brings Google's billing rules with it, and the website already sells them.
Candidate: complete
- Search and filters by role and city
- One-tap apply
- Application tracking
- Saved jobs
- Resume and photo upload
- English and Hindi
Dealership: lite
- Sign in
- Post a job
- See applicants
- Shortlist or reject
- Call a candidate
Waiting for v2
- Buying plans in the app
- Resume database search
- Excel export
- HR team management
- Salary guide and interview tips
- Career chatbot
(What I ruled out)
Three ways to build it, one that made sense
The cheapest option was also the one most likely to fail review, so the decision was made on paper before any code.
| Option | Verdict | Why |
|---|---|---|
| Website in an app shell | Ruled out | Google Play rejects apps that are just a website, and a 2.9 MB desktop-first bundle would feel slow |
| Flutter | Ruled out | A new language, and nothing carries over from the existing React web app |
| React Native with Expo | Chosen | The web app is already React and Redux, so the API layer follows the same shape; one codebase can ship iOS later |
(Values)
What I wouldn't trade away
The server stays as it is
The app talks to the portal's existing API. If something was wrong on the server, I wrote it down for the client's team instead of working around it silently.
Small phones first
Every screen at 320, 360 and 412 dp, because a candidate on an older phone deserves the same app.
Production, not a concept
Data-safety answers, an account-deletion page and a store listing in both languages, because Play needs all three.
The client owns it
Accounts, source code and the signing key sit in the client's name, not mine.
(Mood board)
AutoJobs blue, made readable
The brand already had a blue. I generated a full Material 3 scheme from it, so every text pair stays at 4.5:1 or better in both themes, and kept colour for meaning: green when you're shortlisted, amber for a warning, red for an error.
From the app's Material 3 colour file and its screens
- AutoJobs blue
#0A66C2 - Primary
#004E99 - Container
#BFD5FF - Background
#F9F9FF - Text
#191C21 - Shortlisted
#006C50 - Warning
#974806 - Error
#BA1A1A
- Familiar
- Readable on a small phone
- Bilingual
- Calm, not flashy
(What I built)
One Android app for both sides of hiring
I built AutoJobs v1.0.0 for Android with Expo, React Native and TypeScript, on the portal's existing server, and handed it over with everything Google Play asks for.
- Job search and filters
- One-tap apply
- Application track
- Saved jobs
- Resume and photo upload
- Dealership: post, review, shortlist
- English and Hindi
- Light and dark
- Play Store kit
The screens
One Android app for both sides of dealership hiring — job seekers search, apply and track; dealerships post jobs and shortlist — on the portal's existing server.
(Up close)
The decisions, on the screen
12345- Says what the app is for, in the candidate's words
- Search by job, role or city: the way people actually look
- Applied, shortlisted, saved: the three numbers that matter
- The latest application's track, on the home screen
- Five tabs, labelled, no hidden menus
1234- The status is the headline, not a footnote
- Good news is said in plain words
- Each step explains itself: what happened and what comes next
- "Status is updated by the dealership": who's responsible is clear
1234- Switch language from any screen
- Hindi written for the task, not machine-translated labels
- Role chips in Hindi, the way people search
- The tab bar is translated too
(System)
A new front end on an existing system
The app doesn't own any data. It's a phone-shaped front end for the AutoJobs server, so the website and the app share one source of truth.
Simplified
- ScreensExpo Router, one file per route
- Languagei18next, English and Hindi
- DataRTK Query, cached server calls
- ServerThe existing AutoJobs API, unchanged
- ReleaseEAS build, Play App Signing
- Expo · React Native · TypeScript
- Material 3 theme from AutoJobs blue
- Secure token storage
- Light and dark
- Account deletion page
(States)
Beyond the happy path
- GuestJobs can be browsed without an account. Home says "Namaste!", and applying asks you to log in.
- Skipping onboardingEvery onboarding step can be skipped; the app still works.
- 320 dp phoneEvery screen checked at the narrowest common width.
- HindiEvery label, button and empty state in both languages.
- Dark modeEvery screen checked in both themes, with contrast kept.
- Deleting an accountThere was no deletion endpoint on the server, so the app links to a web page and the request is handled by the team, as Play requires.
- Server gapsProblems the app couldn't fix, including one security issue, went to the client's server team in writing.
(Testing)
What I didn't want to leave to chance
Every button on every screen was tapped automatically, as a guest, a candidate and a dealership. Anything that would write data was answered with a test response, so no live record was changed.
Then the same screens at four widths, in two themes and two languages.
- Expo health checks
- 21 of 21
- Widths checked
- 320, 360 and 412 dp, and tablet
- Every screen in
- English and Hindi, light and dark
(What I learned)
AutoJobs taught me that most mobile work is respecting what already exists. The server stayed as it was. My job was making it usable in someone's pocket, in their language.
Need something like AutoJobs?
Tell me what you want to build. I'll reply with how I'd build it, a rough timeline and a cost range. Free, and no obligation.
Next project
Parsley