Sell applicants, not listings

The initiative in one sentence: change what we sell from "a job listing" to "a promoted post that delivers 20–40 applicants", by fixing the apply flow and showing paid posts to the audience we already have — while the migration squads keep collapsing two systems into one.

What this document is

This is the source of truth for the monetisation strategy, agreed on 2026-07-02 and 2026-07-03. It exists so that:

• Every problem statement is backed by data, not opinion.
• The strategy can be defended to management with numbers.
• The work can be broken down into epics in jod-app/roadmap, each tracing back to a problem on this page.

Where the data comes from

Every number on this page was independently verified on 2026-07-02 / 2026-07-03. Nothing is estimated from memory.

Source	Scope	Window
GA4 jodapp.prod.web (515821279)	jodapp.com + gig-partners web, Singapore	2026-04-02 → 2026-06-30
GA4 jodgig-mobile-app (201038032)	the legacy worker app	2026-04-02 → 2026-06-30
Google Search Console	sc-domain:jodapp.com, Singapore	2026-04-01 → 2026-06-30
Ads::Campaign dashboard	2 campaigns for Seonggong Prestige Pte Ltd	15–22 Apr and 1–8 May 2026
Code audits	jodapp-api, jodapp-web, jodgig-api, JOD_MobileApp_V3_GLOBAL	main branches, 2026-07-02/03

---

The problems

Problem 1 — A paid job post is invisible

When a company pays to post a full-time job, almost nobody sees that post.

• The median full-time job post is viewed by about 19 unique visitors in 90 days.
• The top 2 posts take 48% of all full-time job views. A typical post gets far less than the average suggests.
• Even a perfect apply flow (100% of visitors apply) gives a median post only ~19 applications. Competitors set the expectation near 100.
• Meanwhile, the attention exists on our own site — we just never route it to paid posts:
  • The /jobs list was viewed 35,914 times last quarter.
  • The mobile app has 20,935 active Singapore workers who can receive push notifications.

Evidence: Strong

GA4, Singapore, 90 days:

• 74 full-time (careers) job pages in total.
• Median page: ~19–22 unique visitors.
• The top 2 pages take 48% of the 4,984 careers detail views.
• The /jobs list: 35,914 views in the same period.
• The app: 20,935 Singapore active users.

Problem 2 — The apply flow loses almost everyone

Of the people who view a full-time job page, only 0.68% complete an application.

• The current sequence a new visitor must survive:
  • Log in, or sign up with an email verification code.
  • After sign-up, they are sent back to the login page to log in again (a bug we found in the code).
  • Complete a 6-step profile wizard. Three steps are hard gates: salary expectation, education, skills.
  • Return to the job page and finally click Apply.
• Result: 347 people started this sequence in 90 days. 18 completed an application.
• The gig side proves the problem is the flow, not the users: gig applications convert at ~4.4% — six times better — with no wizard.

Evidence: Strong

GA4, Singapore, 90 days:

• Full-time: 18 users completed an application on jodapp.com — 0.68% of 2,646 careers-page users.
• Gig: 146 users completed applications on gig-partners — ~4.4% of 3,334 gig-page users.
• The wizard sequence is verified in the jodapp-web code.

Problem 3 — Employers cannot see fit, even when applicants fill in everything

The client complaint was not only "too few applicants". It was "none of them fit the role".

• Every recorded full-time application today comes from someone who completed the entire wizard — and employers still said "doesn't fit".
• This proves: a filled-in profile is not a fit signal.
  • The wizard collects CV paperwork: education history, salary expectation, a skills list.
  • Employers mean concrete things by "fit": legal right to work, weekend availability, experience in this kind of role, distance from the outlet.
  • We never ask any of those questions.
• We also hide our best quality signal:
  • For workers linked to the gig system, we already sync their verified work history — completed jobs, total hours, average rating — onto their talent profile.
  • The employer dashboard never shows it. No competitor can show verified attendance data; we have it and don't use it.

Evidence: Strong

Verified in code, 2026-07-03:

• The wizard gates are in jodapp-web: salary, education, and skills each block the "Next" button.
• The verified gig history exists on talent_profiles in jodapp-api: gig_total_completed_jobs, gig_total_working_seconds, gig_avg_rating.
• The sync populates these columns. No employer-facing screen shows them.

Problem 4 — We tested "reach without a working apply flow". It produced zero web applications.

Seonggong Prestige ran two Ads::Campaign purchases. Their banners filled every ad placement on the site for two full weeks. This was a real-life experiment: distribution alone, apply flow unchanged.

Campaign totals:

	Campaign 1 (15–22 Apr)	Campaign 2 (1–8 May)
Impressions	22,368	~23,900
Unique clicks	242	~117
Average click rate	1.16%	~0.5%

Click rate by placement (clicks / impressions):

Placement	Campaign 1	Campaign 2
Home — hero	41 / 3,159 (1.36%)	24 / 3,516 (0.8%)
Home — after hero	39 / 3,154 (1.4%)	28 / 3,516 (0.8%)
Home — middle rectangle	30 / 3,158 (1.04%)	21 / 3,402 (0.65%)
Home — bottom banner	31 / 3,155 (1.11%)	20 / 3,401 (0.71%)
Job list — inline banner	13 / 5,888 (0.22%)	9 / 6,054 (0.18%)
Job detail — inline banner	84 / 3,590 (2.42%)	14 / 3,729 (0.38%)
Contact us — top	2 / 64 (3.13%)	0 / 80 (0%)
FAQ — top	2 / 200 (1%)	1 / 213 (0.47%)

What happened after the click (GA4, 14 Apr – 10 May, this client's pages):

• The clicks landed on the client's company page, which correctly lists their jobs: 471 users visited it.
• About half went deeper: 238 users opened actual job pages (service crew, kitchen helper, two full-time roles).
• Then: zero. Not one job_apply_start and not one generate_lead event on any of this client's pages in four weeks.

What this experiment teaches us:

• Interest exists. 238 people read specific job pages after clicking an ad. People who don't want a job do not click through two pages.
• The apply step is where everything dies. Most of the client's roles are gig jobs — clicking Apply sends a web visitor to gig-partners and asks them to log in to an account they don't have. The full-time roles route into the Problem 2 wizard.
• Cards beat banners. The banner inside the job list was the worst placement (0.22%, then 0.18%) — yet on that same page, about half of all users open a job card. Same eyes, same page: a job-shaped card is engaged with at a far higher rate than a banner-shaped ad. If we sell placement on the list, we should sell pinned job cards, not banners.
• Small audiences wear out fast. The same creative shown again two weeks later earned half the click rate. Distribution on a small site must rotate creative and, more importantly, grow the audience (Problem 5).

Evidence: Strong

Campaign numbers: the Ads::Campaign dashboard, both campaigns, transcribed 2026-07-03. Post-click numbers: GA4, pages containing "seonggong", 2026-04-14 → 2026-05-10:

• Company page: 690 views / 471 users.
• Job pages viewed (view_item): 430 events / 238 users.
• Apply attempts (job_apply_start): zero.
• Completed applications (generate_lead): zero.

Problem 5 — Traffic is small, flat, and full-time jobs are invisible on Google

Fixing conversion raises the value of each visitor. But the number of visitors is the long-term ceiling.

• Organic search brings about 960 clicks per month, flat for three months (Apr 927 → May 1,001 → Jun 951).
• Full-time job queries: 47 impressions, 0 clicks in three months. Our paid product has no organic presence at all.
• Improving click rate on existing impressions caps out around 2x. The real ceiling is impressions — we need more pages that rank (category pages, employer pages).
• We also know the words to use, from what users actually type:
  • "part time": 9,578 impressions (our internal word "adhoc": 1 impression).
  • "daily pay": 7.9% click rate vs the 1.39% non-branded average — our best-performing theme.
  • Employer-name searches beat neighbourhood searches 13:1 (13,612 vs 1,033 impressions).

Evidence: Strong

Google Search Console, Singapore, 2026-04-01 → 2026-06-30:

• Total: 2,879 clicks / 76,494 impressions.
• Branded queries take 24% of the clicks.
• Monthly clicks are flat: Apr 927 → May 1,001 → Jun 951.
• Full-time query family: 47 impressions, 0 clicks.

Problem 6 — Gig work happens in the mobile app; the website is only the front door

• The app (Singapore, 90 days): 20,935 active workers, 16 sessions per user, 38.7 minutes engagement per user, 81% returning.
• Applications: 1,528 workers completed applications in the app vs 146 on gig-partners web vs 18 on jodapp.com — the app leads 10:1.
• Shift operations (QR clock-in/out, acknowledgements): app only, ~1,300 workers.
• The web's role is different: it brings 26,881 new users per quarter (the app: 8,608) but they stay 1.4 sessions and under 2 minutes.
• Two consequences:
  • We cannot sunset the app until its operational features exist elsewhere.
  • The app is our strongest unused distribution channel — push notifications reach more engaged workers than the entire website's traffic.
• One warning sign: app weekly actives are flat at ~4,800 all quarter. The app retains; it does not grow. Growth comes from the web (Problem 5).

Evidence: Strong

GA4 property jodgig-mobile-app (201038032), Singapore, 90 days, verified 2026-07-03.

Problem 7 — Running two systems taxes everything

• 8 engineers maintain: 2 backends (Rails, Laravel), 3 web frontends, 1 mobile app.
• jodapp.com cannot measure its own core success event — a completed gig application is recorded on gig-partners, and the handoff carries no login, so users must sign in twice.
• The good news, verified in code: the Talent Sync approach was right. It already built the mapping column (remote_gig_user_id), password compatibility across both systems, and just-in-time account migration. The missing half is a write path into jodgig — designed as the single-login bridge (decision note to be written in 31-identities).

---

The strategy

Four parts. Parts 1 and 2 earn revenue; parts 3 and 4 make the earning durable.

Part 1 — Make a paid post deliver 20–40 applicants

The 20–40 target is arithmetic, not hope: a promoted post shown to a few hundred people (instead of 19), through an apply flow converting ~4–5% (instead of 0.68%), yields 20–40 applications. Both levers must ship together — Problem 4 is the proof of what happens when distribution ships alone.

Epic A — Fix the apply flow, with screening questions in the same spec.

• Record the application first, with the smallest identity step (name, phone, email, one verification code).
• Include the employer's 2–4 screening questions at apply time (tap-to-answer: work rights, weekend availability, years of experience). This is the fit signal Problem 3 says employers are missing — it is part of this epic, not a later add-on.
• Remove the sign-up → log-in-again bounce.
• Move profile completion to after the application is recorded, with a plain incentive ("employers respond more to applications with work experience").
• Redesign the employer's applicant card to lead with: screening answers ("meets 3 of 4 requirements"), verified gig work history, phone verified, distance from outlet.

Epic B — Build the distribution surfaces.

• Pin promoted posts at the top of the /jobs list — as job cards, not banners (Problem 4's placement data).
• Show a featured-jobs row on the home page.
• Add "similar jobs" and "more jobs from this company" on every job page (today a visitor who dislikes one job has nowhere to go).
• Send email alerts to job seekers when a matching job is posted.
• Spec the sales-set "featured" flag first — no spec exists anywhere today.

Epic C — Push distribution through the app.

• Push a paid post to app workers whose profile matches it. The deep link that opens a specific job already exists.
• This is the closest thing we have to how fastjobs delivers applicant volume, and it reaches workers who never visit the website.

Epic D — Quick wins and measurement.

• Add the jodapp.com-native apply event (without it, we cannot prove any of this worked).
• Make the Apply button stay visible on mobile.
• Make the home-page keyword suggestions clickable.
• Decide with billing what to do with the AdSense fallback in the apply path (it earns cents per day and sits where users decide to apply).

Part 2 — Grow the visitors (the compounding lever)

• Category landing pages, using the demand-matched category set.
• Employer pages tuned for employer-name searches (13:1 demand).
• Use the users' words — "part time", "daily pay" — in titles and copy.
• Google-for-Jobs structured data hygiene.
• This work raises the ceiling that Part 1 operates under. It is also the natural next assignment for the squad finishing the JodRewards SEO warm-up.

Part 3 — One platform

• The two reserved squads (Gig migration, Billing) stay on course. Their projects are the strategy — do not pull them into feature work.
• Add the single-login bridge: jodapp is the account of record; a small, disposable, secured endpoint on the Laravel side records gig applications; the user never logs in twice.
• The mobile app: contain, do not rebuild now.
  • Make it safe: automated builds (CI), signing keys and secrets into a shared vault, rotate the keys found committed in the repository.
  • Freeze features except push notifications (Epic C depends on them).
  • Decide native-vs-web when the Gig migration designs the worker experience on jodapp. If a native app is still needed then, rebuild once, small, against the new Rails APIs.

Part 4 — Billing: sell manually first, automate second

• Selling featured placement does not wait for the entitlement engine.
• First customers: sales sets the featured flag by hand, finance issues a Phase 2 invoice.
• Phase 3 (entitlements, boost, self-serve) automates a product we will have already proven people pay for.

---

Squads

Squad	Now	Next
Gig migration	Continue (Part 3)	Single-login bridge, when the gig apply design lands
Billing	Finish Phase 2 (Part 4)	Phase 3 entitlements, timed to distribution demand
Employer sync	Finish the sync	Epic A (apply flow + screening) — they know the identity code
SEO warm-up	Finish JodRewards	Epic D + Epic B frontend, then Part 2 landing pages

What we deliberately postpone

Postponing is a decision, not a failure — say it openly:

• The home page redesign.
• The full navigation and taxonomy restructure from the IA research.
• The mobile app rewrite.
• Any third-party identity provider.

The IA research stays valuable — it is where the funnel numbers, the category set, and the apply-flow findings came from. We take its items in revenue order, not document order.

Targets

Metric	Today	Target
Applications per promoted post	2	20–40
Full-time apply conversion (job-page visitor → recorded application)	0.68%	3–5%
Visitors per promoted post (90 days)	~19	hundreds
Applicants matching employer's screening criteria	not measurable	shown per post
Completed applications measurable on jodapp.com	no (careers only)	yes, all

From this page to GitHub

Each epic above becomes an issue in jod-app/roadmap, written in the three-act format (Context → Problem → Direction) and linking back to the problem it solves on this page. Epics A and D go first — the squads working on them free up soonest.